It’s December 2017. You’ve probably already migrated your legacy infrastructure to the cloud, got yelled at by your CFO for ever increasing cloud provider bills, and started to recognize that operating an Infrastructure-as-a-Service (IaaS) vendor like a data center isn’t working out. You want to start fresh and build a next-generation environment that’s truly elastic, durable, repeatable, and cost-effective. You want to go Cloud Native.
Cloud Native changes everything. It is not just about DevOps, micro services, or containerization. Rather, Cloud Native fundamentally changes the way we prioritize development, architect for scaling, and define and manage technology assets.
In a traditional, non-cloud hosting environment, companies spend too much CapEx upfront to set up an environment (e.g. bare metal, networking, and standard OS build) before anyone can do a proof-of-concept or run a real-world test. In a Cloud Native model, companies can quickly provision cloud based resources to vet new ideas. Similarly, development organizations can embrace failing fast and often without disruption. Of course, architecting a worthy cloud infrastructure still requires serious expertise and deep understanding of how much of a resource is really required, but this allows companies to focus engineering efforts on building a product that customers desire.
Elasticity is one of the most important objectives when designing a Cloud Native application architecture. True elasticity means dynamic scaling with a money-saving conscience. While most of the cloud providers offer turn-key functionality to scale vertically, it is up to you to design for horizontal scaling. Cost-wise, current cloud pricing structures favor horizontal scaling (i.e. spinning up multiple smaller instances), which makes sense from a cloud vendor operation perspective. To be able support dynamic scaling, you would at least need to consider the following design decisions from the very beginning:
- Do I understand my traffic pattern enough to assume proper scaling conditions?
- How do I build and maintain a loosely coupled stack?
- How do I scale shared resources and handle concurrency?
- How do I maintain states and perhaps build a scalable state machine?
- Do I scale out my data storage with DB-as-a-service or asynchronous replication?
- Containerization or not, which deployment strategy makes the most sense?
- What are my bottlenecks?
Furthermore, in order to achieve a highly durable Cloud Native environment, we need scaling and recovery to be a repeatable process. Google’s SRE team puts it nicely in their book Site Reliability Engineering:
Site Reliability (Engineering) isn’t just about automation, it’s about the site being automatic (recovering).
As the number of configurations grows exponentially, you need to think beyond configuration management and really tackle how to manage your technology assets. The overarching “infrastructure-as-code” concept requires you to first identify your assets, the metadata of those assets (such as dependencies, versions, and states), and utilization. Then capture assets, tangible and intangible, as file-based documents.
From this, create a Technology Asset Management solution that incorporates configuration management tool(s), a repository, and an orchestrator that CRUDs these assets along the way. At Ten Mile Square, we prefer a more declarative vs. procedural style for defining assets and configurations as this enforces a higher level of repeatability by offloading the responsibility of maintaining idempotency to the environment. The goal is to deploy, scale and recover any version of an asset repeatedly with a high degree of consistency and confidence.
Transitioning to Cloud Native allows you to attune to the ever-changing market, but it also requires that you reach a new level of operational awareness and capability. Design for future scaling, but provision resources for existing demand. Just like any architecture model, Cloud Native is not a one-size-fits-all.
Ten Mile Square can help you sort out how to best leverage cloud services and whether a Cloud Native approach is the best fit for your business needs and priorities.