The funny thing about clouds is that not everything is designed to be up there. Birds, sure. They have wings, and can soar among the clouds. Airplanes? You bet…they have powerful engines meant to be up high.
But legacy applications? Not so much. Moving an app as-is to public IaaS or private cloud doesn’t mean it’s going to function as hoped for in the cloud environment.
So, what does it mean for an application to be “cloud-native”? Our guest Tony Bourke is going to help the Datanauts understand the fundamentals of applications designed to live in the cloud. Tony is a Cisco-certified IT instructor and he blogs at The Data Center Overlords.
Part 1 – Understanding Legacy Application Architecture
- The typical architecture of a Web application
- Pool members
- What happens when we want to scale out this infrastructure?
- More pool members
- Takes a while to use the new pool members. (Because stickiness)
- Statefulness is the big thing here
- TCP statefulness, sure, but that’s not the biggest deal
- Application state is the big deal, and the concern. (Again with the stickiness)
- Why is it a problem when we take an app with this design and move it to cloud infrastructure?
Part 2 – Understanding Cloud-Native Architecture
- Acknowledging that there is disagreement on the definition “cloud native.” Here are some other terms that are used in conjunction with “cloud native”
- 12 Factor Applications (12factor.net)
- Mode 2 (from bi-modal IT)
- Third platform (Kit Colbert of VMware used this term)
- What defines the older-style applications?
- Mode 1
- Traditional applications
- What are characteristics of a “cloud-native” application?
- Horizontal scalability
- State is shared across nodes, so adding or removing nodes is seamless
- Does not rely on vmotion
- Typically involves continuous integration/continuous delivery (DevOps) for rapid deployment of new code
- Often (but is not required) runs on containers
- Closely aligned with microservices
- Tools that developers use to create these cloud-native applications
- Platforms as a Service
- Cisco Mantl
- Kubernetes (Google)
- Apache Mesos
- Pivotal Cloud Foundry
- Shared key/value pair stores
- Backend databases (NoSQL and SQL)
- Sharding support to handle scale of databases
- Sharding of data/applications
- Hashing algorithms (similar to how LAG works)
- Platforms as a Service
- The purpose of applications aren’t radically different just because they are now in the cloud
- We aren’t creating some fantastical world that’s hard to comprehend
- It’s still infrastructure we recognize. There’s still an HTTP server in there somewhere
- What changes need to be made to an application to become cloud native?
- Let’s get rid of that stickiness
- Let’s mirror state
- Now what happens when we need to scale out to service incoming requests?
Part 3 – Retooling Applications For Cloud
- How do we retool applications to become cloud-native? Do we even need to? How do we evaluate that?
- Are you bad at IT if you aren’t 100% cloud native with containers and microservices? The echo chamber seems to think so …
- Operational impact – what’s it like to be an infrastructure engineer in a cloud-native environment?
Netflix finishes its massive migration to the Amazon cloud – Ars Technica
Traditional vs Cloud Native Applications – Tony Bourke YouTube video
The Phoenix Project (Gene Kim’s book)
Migrating to Cloud Native with Microservices – Adrian Cockcroft (YouTube)
Docker and DevOps – Gene Kim (YouTube)
The Data Center Overlords – Tony Bourke’s blog