Comparing Azure Deployment Model and PAAS with Duplo-on-AWS
I started using AWS sometime in 2015 and was very impressed with performance and functionality. A VM would come up running within seconds of launch; security groups and IAM policies would get applied instantaneously. This was significantly better than in Azure experience back then. Being from a strong networking and cloud background the prerequisites for creating an application in AWS like VPC, security groups, subnets, IAM etc did not bother me. My social interactions were also with friends and acquaintances with similar background. Nothing seemed amiss in the deployment model. This changed when I was exposed to full stack application developers in an SMB like Zenefits. Most did not know what the term “VPC” stood for. They had no control over the infrastructure for their application and relied on a central infrastructure team. There was no self-service. I realized how incredibly complex the AWS deployment model is for that audience and in my earlier blog I had described this problem in detail.
I thus founded the startup Duplo that implements an abstraction on top of AWS to addresses this problem. When I interact with a potential SMB customer hosted in AWS with limited Devops resources, we are in sync with the problem statement and the Duplo solution seems to make total sense. They could not care less what is the behind the scenes implementation. Duplo doesn’t get compared with terraform\cloud formation or Kubernetes or cloud orchestrators like Cliqur or Apprenda. Besides not every customer has the ability or desire to invest in building infrastructure-as-code. Particularly when it is hard to hire developers for their product let alone to build infrastructure. They would rather prefer that AWS cloud platform natively implements a simple and secure deployment model. Duplo just gave them that.
When I interact with some other customer devops leaders who have already invested in automation tools like terraform; or friends, acquaintances and VCs with a no-devops background; I see that their understanding of Duplo from my previous blogs, seems to be one of Duplo being as “another cloud orchestrator”, “config management tools like terraform, Elastic Bean Stalk” and at times even Kubernetes. More recently I have been saying “Duplo is the Heroku for AWS”. I think I have not done a good job at describing core Duplo pieces for this audience. This blog is my attempt to address this.
- Intra-Account Multi-Tenancy (Subscriptions) in Azure vs none in AWS
Aws is multi-tenant at an account level. A typical organization would have a single or a very few accounts. Fundamental to self-service is the ability to create an isolated sandbox environment for each application team where any resource they create or modify is isolated within that sandbox. This cannot be achieved natively within the same AWS account. IAM user or role is an RBAC concept and does not provide multi-tenancy within an account. For example say users in front end team would like to create a set of VMs for themselves only. They can be given an IAM user with EC2:CreateInstance; EC2:DescribeInstances permission but this does not mean that the VM they create will not be visible to another team with same access. In other words IAM permissions are at a resource “type” level or at a level of resource that “already” exists. Hence what ends-up happening is that all requests for resource management are routed through a central Devops team who in turn create these resources with name tags prefixed with the application name. Then applying IAM access policies linking these “already” created resources to the users who requested them. They are effectively maintaining a “tenant” out of band either via terraform scripts or a simple document. This is referenced every time a new configuration is to be made.
In Azure in addition to the concept of an account and AD user, there is a concept of “subscriptions” within an account; a construct that is missing in AWS. In this example, each application team can be a subscription. Users can be given subscription level access and resources are scoped within the subscription. Subscriptions can share base infrastructure like VPC, subnets etc and are not over-isolated.
Duplo implements an abstraction on top of AWS to achieve this missing construct. Users are authorized via Google Oauth or Microsoft AD. One Duplo instance is deployed per account. Each application team is a tenant, engineers identified by their email (Oath), have permission to access one or more tenants. Each tenant is isolated from others by default. Any resource created in any given tenant is by default scoped to that tenant. No-out-band resource to application team mapping is required to be maintained by devops team and hence enabling developer self-service in the platform. Tenants share base infrastructure policies like VPC, subnet etc. setup by the admin.
2. Azure Service Model\ARM vs None in AWS
AWS is a disparate collection of hundred odd cloud services that are loosely tied together by a single UI i.e. AWS console. Each resource has its own interface and it is up to the users to create the desired resources, setup the relationships and access policies between them. All these configurations have to be managed out-of-band and the final configuration applied to AWS as a loosely ordered sequence of API calls. AWS does not natively have a concept of an “application or service”. So effectively it is upto the user to implement a declarative interface out-of-band. None of the tools today like terraform, cloud formation or Elastic Bean stalk suffice. Besides not every customer has the ability or desire to invest developers in building infrastructure-as-code. I describe this problem in detail with examples in this other blog.
Azure, on the other hand, always started and has maintained a declarative service model. Originally it was called cscfg\cspkg and more recently Azure Resource Manager (ARM) template. The ARM component is responsible to parse the service model stitch together the application dependencies by interacting with disparate Azure infrastructure services (Resource providers).
Duplo being an abstraction above AWS implements its own declarative service model for AWS constructs and is responsible to stitch together the complex AWS dependencies by interacting with individual service APIs. In-fact Duplo Service Model goes beyond AWS to support third party services like Sumologic, Signalfx etc. In Duplo, all changes are made in the context of the tenant the user is operating in.
Let’s take an example to describe the Duplo experience on AWS. Say on Day 0 a user operating in the context of a certain Duplo tenant, creates a set of EC2 instances and a couple of S3 bucket. He does not have to create any access policies between them because Duplo would do it implicitly by calling EC2, S3 and IAM APIs. Similarly say on Day 2 if the user comes and add a dynamo DB table in the same tenant then Duplo would implicitly add a policy to make it accessible to EC2 instances within that tenant. All along the user is operating in terms of his application requirements and not configuring underlying infrastructure dependencies. Seems like a simple concept but complex to implement.
3. Azure Cloud App and PAAS (Rolling Upgrades) vs None is AWS
In Azure further within subscription one has a the concept of web app. Rooted at this are azure PAAS features like rolling upgrade. In AWS, ECS is probably the only one that comes close to this and implements rolling upgrade of Docker containers. But no such concept exists for non-Docker applications. Besides ECS is a rather primitive container orchestration software missing most basic features like flat networking, not being able to run two containers on same port among other limitations as described in this other blog.
Duplo implements a concept of a “Service“ within a tenant. Rolling upgrades is supported for services that are Linux\Windows Docker containers and non-Docker Windows applications. Support for native Linux applications is TBD. For native Linux services, Duplo can still provide a declarative service model to integrate with ELB, S3 and other services but it cannot do, at this point, rolling upgrades.
4. Group-of-Applications in Duplo vs Nothing is Azure in and AWS
An organization might have tens or hundreds of applications running. Often there are a set of policies like VPC IDs, subnets, security groups, resource limits etc. to be shared across them. Then there are common platform services, one instance of which is required to be deployed within each tenant. Sumo logic collector, signalfx collector and nginx are some examples. This configuration is managed by the administrator and it is desirable to group tenants into multiple “plans” where each plan has its own value for this configuration. Duplo implements this construct and calls it a “Tenant Plan”. I see Duplo customers have dev-plan, beta-plan and prod-plan, an example of how it can be applied.
In addition to applying policies for tenants in the plan, Duplo provides a rolling upgrade mechanism on a per plan basis. For example, say an organization’s sumo logic key which has been set in the sumo collector platform service needs to be changed, then the admin can make the change in one plan and wait for Duplo to upgrade all tenants in the plan and thus ensure the sanity of the change and subsequently update other plans. In the absence of such constructs these upgrades are done manually tenant by tenant the admin by making sure that each tenant\batch is healthy after the upgrade.
Those who work in public cloud infrastructure would relate to this mechanism with the batch configuration and upgrade process of the physical server configuration in their data centers.
5. Integrated CI\CD environment in Duplo vs None is Azure in and AWS
It is common for CI environment configuration (like VPC, security groups, certificates etc.) to be different than the production environment. In case of monolithic application since the deployment configuration is rather constant it is easy to keep the CI and production consistent. But when it comes to micro-services it gets harder given the complexity of deployment topology where many services are interacting with each other. It is common that a certain change passes in the CI environment but might fail in the production settings. To mitigate this, organizations manually set up a stage or a pre-prod environment to repeats the tests. Still CI and CD are considered two separate functions.
Duplo integrates CI and CD by providing a CD/CD instantiation within a tenant. Each tenant can be linked to a repository and the service model for the application be saved in the repository. A user first triggers a CI run which spawns a temporary micro-service (with Jenkins Docker Image) in “same tenant” and executes the CI for the repo and then once complete, it deletes the micro-service in the tenant. Effectively the CI was run in the same tenant deployment topology. Once CI passes another run would deploy\upgrade the application in the tenant based on the service model in the tenant’s repository. One tenant can be linked to multiple repos and vice versa. Azure and Amazon have no such thing.
6. Tools Ecosystem Orchestration in Duplo vs None in AWS & Azure
Every micro-service typically needs a set of tools like sumo, splunk for log aggregation; signalfx, cloudwatch for monitoring, cloud ability for billing etc. Duplo orchestrates these tools by exposing them through the service model. For example, if asked for “sumo logging” in the service model, Duplo would implicitly spin off one sumo collector per host in each tenant. It would set the collector name to the tenant name and automatically map the application logs folder captured by docker per container to the sumo collector. The net effect is that a developer needs to write ZERO lines of code (beyond logging to stdout) and still all his logs land up in sumo; partitioned by application, service and containers.
There are several other minor features in Duplo which integrate into its service model. The interface for developers in Duplo is the service model and tenant plans for Devops team. Hopefully in this blog I have described the technical meat in Duplo. But my pitch to a customer still remains that Duplo is a simpler declarative abstraction on top of AWS that would reduce Devops man hours many folds and proportionately reducing cost and increasing agility. Duplo aims to achieve true DevOps (Developer Operations) by enabling developers to deploy and operate their applications themselves.
Everything else described in this blog is an implementation detail.