How to Assess Your Application to Adopt Cloud-Native Architecture
Overview
Simply rehosting an application into a cloud environment does not make it cloud-native.
Cloud advantages
- Uses dynamic, shared and virtual infrastructure
- Offers a service in an on-demand, self-service model
- Scales rapidly and elastically
- Meters consumption
- Is available across common networks
Cloud-native platform
For example: Cloud Foundry, OpenShift, Amazon Web Services (AWS) Elastic Beanstalk, Azure App Service, IBM Bluemix and Google App Engine.
Target is a cloud-native platform, which supports:
- Agile and distributed development
- Deploying code frequently as a way of reducing risk and delivering faster (continuous integration/continuous development [CI/CD])
- The ability to build and operate complete, full-stack systems
- Developing and testing on identical configurations to production, deploying the same artifact across all life cycle stages and infrastructure through provisioning of new instances (immutable infrastructure and containers
- Designing applications to be resilient and scalable running on cloud-based infrastructure, which has a unique combination of characteristics
Type
- platform as a service (PaaS)
- function PaaS (fPaaS)
- computing as a service (CaaS)
- do-it-yourself on IaaS
The Guidance Framework
Assess the following five core domains of your application:
State/server affinity is the enemy of scalability in a cloud-native environment.
- Application architecture
- Use of Unsupported Languages and Runtimes
- Direct Code-to-Runtime Relationship
- Improper State Management
- Monolithic Design and Deployment
- Single Points of Failure
- Bottlenecks
- Application code
- Hardcoded Values
- Memory Locks
- Blocking Calls
- Siloed Logging
- Nonrestartable Application Components
- Integration points
- Chatty interactions
- Network calls
- Complex call graph
- Use of third-party libraries and APIs
- Data persistence
- Use of multiphase commits
- Monolithic databases
- Use of select * statements and wildcards in SQL statements
- Developer-crafted SQL statements
- Application life cycle management process
- Manual configuration updates
- Manual builds and deployments
- Inability to be containerized
- Inability to roll back releases
- Lack of failure injection testing
Entanglement: Entanglement can be viewed as the number of interdependencies both within and outside of your application.
Risks and Pitfalls
Risk
- Not Investing in Cloud-Native Operations
- Failure to automate processes and the introduction of human error all equate to outages and potential loss of revenue for your business.
- Introducing Additional Complexity Through Distribution
Pitfall
- Positioning Cloud-Native Modernization as a "Project"
- This will leave the majority of operations and development team members "out in the cold."
- Applying This Guidance to Every Application