The term "cloud native" is thrown around constantly when referring to how to build modern applications, but it has been hard to find a consistent and fully encompassing description of what it really means. In this webinar, Kim Clark and Kyle Brown discuss a range of elements that need to come together to take a truly cloud native approach and also consider what some of the key challenges are.
2. Cloud native – the bigger picture
Market
Growth
Risk
Mitigation
Cost
Reduction
Agility and
productivity
Resilience and
scalability
Optimization and
efficiency
Business
Outcomes
IT
Goals
People
and
Process
Architecture
and
Design
Infrastructure
and
Technology
5. Ingredients of cloud native
Agile
methods
Lifecycle
automation
DevOps and
site reliability eng.
Team
autonomy
Fine-grained
components
Appropriate
decoupling
Minimal
state
Immutable
deployment
Zero
trust
Elastic, agnostic,
secure platform
Lightweight
runtimes
Operational
automation
Observability
and monitoring
People
and process
Architecture
and design
Technology
and infrastructure
6. Microservice
architecture
Ingredients of cloud native – hard lessons learned
Initial concepts Adoption hurdles Success factors
Agile
methods
Lifecycle
automation
DevOps and
site reliability eng.
Team
autonomy
Fine-grained
components
Appropriate
decoupling
Minimal
state
Immutable
deployment
Zero
trust
Elastic, agnostic,
secure platform
Lightweight
runtimes
Operational
automation
Observability
and monitoring
Container
technology
Ubiquitously
automated
Roles
and
responsibilities
Sustainably empowered
Secured by default
Managed in aggregate
People
Architecture
Technology
7. Ingredients of cloud native
People
and process
Architecture
and design
Technology
and infrastructure
Agile methods
• Short, regular iteration cycles.
• Intrinsic business collaboration
• Data driven feedback
Lifecycle automation
• Continuous Integration – Build/test pipelines
• Continuous Delivery/Deployment – Deploy, verify
• Continuous Adoption – Runtime currency
DevOps and site reliability engineering
• Collaboration and combination of dev. and ops. roles
• Shift left for operational concerns
• Rapid operational feedback and resolution
Team autonomy
• Decentralized ownership
• Technological freedom
• Self-provisioning
Fine-grained components
• Function driven granularity
• Self-contained components
• Independent lifecycles, scaling and resilience
Appropriate decoupling
• Clear ownership boundaries
• Formalised interfaces (API and event)
• Independent persistence
Minimal state
• Uncomplicated horizontal scaling
• No caller or session affinity
• No two phase commits
Immutable deployment
• Image based deployment
• No runtime administration
• Updates and rollbacks by replacement
Zero trust
• Minimized privileges
• Implicit data security
• Shift Left for security (DevSecOps)
Elastic, agnostic, secure platform
• Elastic resource capacity
• Agnostic deployment, and operations
• Secure by default
Lightweight runtimes
• Fast start up/shut down
• File-system based install and configuration
• File-system based code deployment
Operational automation
• Infrastructure as code
• Repository triggered operations (GitOps)
• Site reliability engineering
Observability and monitoring
• Easily accessible status
• Platform neutral logging and tracing
• Cross component correlation
8. What are the challenges of cloud-native?
•Just moving your current application into a container won't gain you the benefits of cloud native. Unless your application
behaves like a cloud native component, your pipelines are automated, and your methods are agile etc. then you will see little
benefit from the move. https://developer.ibm.com/technologies/containers/series/benefits-of-containers
Lift and shift to containers
•Breaking something up into fine grained components is largely pointless if they remain dependant on one another – just end up
with a distributed monolith. Reducing dependencies involves significant refactoring, it doesn’t just happen. The components
don’t have to all end up fine grained, some can be larger if that makes more sense. https://kylegenebrown.medium.com/whats-
the-right-size-for-a-microservice-bf1740370d47
Distributed monolith
•Diagnosing problems on a highly distributed system is fraught with challenges, and is even harder when the components are
ephemeral. Significant thought needs to be put into what information is captured and how it can be analysed.
What happened where?
•Some components are inherently stateful. Indeed for some it is their job to manage state (think databases, queues, event stores
etc.). Choices will have to be made around what aspects of cloud native deployment are highest priority. CAP theorem still
applies.
Something has to own the
state
•Not all components need the indefinite elastic scalability so often promised by cloud native. Very few applications will ever be hit
by extreme unplanned load. Designing for limitless horizontal scalability is complex and potentially expensive. For most, the
priority is horizontal stability, which will get you much of what you need for horizontal scaling should you need that later.
https://medium.com/swlh/a-cloud-native-coda-why-you-probably-dont-need-elastic-scaling-46b9315df635
Horizontal scalability or just
horizontal stability?
•Not everything suits short iteration cycles. Some things require and even benefit from an element of the less fashionable
waterfall approach. It doesn’t have to be a high level choice, it could be a component by component decision.
Some waterfalls are beautiful
9. Business outcomes
Market Growth
Reduced time to market
Innovation readiness
Risk Mitigation
Resilience and security
Deployment confidence
Cost Reduction
Optimized high value staff
Elastic cost models
IT goals
Agility and productivity
Faster delivery of business aligned components
Autonomous teams with freedom to innovate
Responsive to rapid feedback
Resilience and scalability
Fine-grained elastic scalability and resilience
Consistent environments and reversible deployments
Continuous adoption of software updates
Optimization and efficiency
Sharable skills on the underlying platform
Optimized infrastructure usage and licensing
Rapid self-provisioning of resources and capabilities
The benefits of a cloud-native approach
10. Cloud native summary
Business
Outcomes
Market Growth
Reduced time to market
Innovation readiness
Risk Mitigation
Resilience and security
Deployment confidence
Cost Reduction
Optimized high value staff
Elastic cost models
IT Goals
Agility and productivity
Faster delivery of business aligned components
Autonomous teams with freedom to innovate
Responsive to rapid feedback
Resilience and scalability
Fine-grained elastic scalability and resilience
Consistent environments and reversible deployments
Continuous adoption of software updates
Optimization and efficiency
Sharable skills on the underlying platform
Optimized infrastructure usage and licensing
Rapid self-provisioning of resources and capabilities
Architecture
and
Design
Infrastructure
and
Technology
People
and
Process
People
and process
• Agile methods
• Lifecycle automation
• DevOps and SRE
• Team Autonomy
Architecture
and design
• Fine-grained components
• Appropriate decoupling
• Minimal state
• Immutable deployment
• Zero trust
Technology
and infrastructure
• Elastic, agnostic, secure platform
• Lightweight runtimes
• Automated operations
• Observability and monitoring
http://ibm.biz/cloudnativedefined