At large scale, so in a cloud environment, everything fails, all the time
— Wermer Voegels, CTO of Amazon
This is a list I use to establish a minimum shared vocabulary and concepts around #Cloud when entering a team, in architecture reviews, and sometimes in interviews. The Cloud brings a drastic change in architecture, especially when “Cloud is now the default”.
(vocabulary , principles, tools and offers).
Feel Free to contribute your favorite resource :-). Ideally, concise and to the point
Vocabulary:
- SaaS (Software as a Service), (software, pay as you go)
- IaaS (Infrastructure as a Service) (AWS EC2)
- Caas (Container as a Service) ( Docker )
- PaaS (Platform as a Service), ( e.g. Heroku or even SalesForce)
more explanations
The Market focus is changing :
IaaS -> CaaS -> PaaS
The concepts changes too :
Minimum Viable Architecture
Make sure your Design handles …: ( concise explanation )
IaaS
Forklift Time , Smart configuration, Health Check URL
CaaS
- MicroServices deployed in container , ( design for location transparency, design for failure)
- Many small machines, not one big
- Stateless code in clusters -> State as a Service
- Filesystems dependencies
- cloud logging services
- going serverless architecture
- pay when you use -> stop when not used ?
-
Development :
- should run locally in one command
- container to deploy
Players, Acronyms, Offers, Tooling
- Container : Kubernetes, Docker
- Amazon AWS : SNS, redshift, Cloudwatch, DynamoDb, S3, EC2, Puppet, Chef, Ansible, Kinesis, lambda
- Cloud & SaaS Platforms: Amazon and Google Web Services, Salesforce.com, Workday, Concur, ServiceNow
- Infra As Code (IaC) : Terraform over Chef, Puppet, Ansible, SaltStack
Principles
- https://12factor.net
- 6 laws” from Werner VOGELS
- The evolution (according to Werner Voegels) :Server -> Container -> Lambda
Stopping Confusions about CAP
( this is a slightly more advanced and less practical section)
When you enter the high availability world, you should know about the CAP theorem.
There is room for confusion when a database guy meet a cloud guy, as terms do not means he same things, like consistency, etc:
– the confusion between the CAP and ACID wording
– The CAP categorization used in marketing has little to do with what the CAP theorem actually is about. Most systems that describe themselves as CP are not all that not partition-tolerant, and most systems claiming to be AP are not all that available.
– CAP is often described as a theorem you cannot avoid using. A common saying is “nodes fail, network packets get lost, partitions arise so you need to use CAP to choose the trade-offs.” Actually, the CAP scope is not that wide. Let’s look at why a process crash or a node failure are not partitions in CAP.
Fun, Retrospective and Prospective
In 2008, I started following this cloud topic, and in 2011, Microsoft was painting the Paris Tube Wall with its “Cloud” campaign, thus installing the cloud buzzword in public culture. (Look at what the landscape was looking like then ..( FR)).
Let me humor this : ..Without changing the way I do things ? Really? .
Prospectively, here is a summary (2015) of the new debates, as I recon we are entering a post-amazon era ( post-(pure)Amazon, I mean ) .
… Without changing the way I do things ? Really ?
