THE CLOUD NATIVE MATURITY MATRIX ASSESSMENT

THE CLOUD NATIVEMATURITY MATRIXASSESSMENT

Where are you in your Cloud Native journey?

ContainerSolutions

container-solutions.com3

INTRODUCTION

Cloud Native is a set of methods for optimising systems for the cloud. The approach harnesses the cloud’s most powerful advantages—flexible, on-demand infrastructure and managed operational services—and pairs them with continuous delivery, containers, microservices, and other cloud-optimised technologies. When done right, it allows you to drastically speed up building, testing, and deploying software–reducing risk while you iterate and innovate ahead of the competition.

The payoff for going Cloud Native is immense, but in order to reach it an organisation must evolve not just its tech stack but also human-centered aspects like culture, process, and leadership. Some companies believe they can simply ‘lift and shift’ their current operations to run on the cloud, and that this will make them Cloud Native. They quickly find out, however, that this is a fast path to failure. Since Cloud Native is still new, few companies have deep experience in navigating the architecture’s complexities.

THE MATURITY MATRIX

A Maturity Matrix outcome graph from a real-world enterprise assessment. It shows both the company’s current status and the progression points necessary for evolving into a Cloud Native entity.

container-solutions.com 4

While guiding companies onto the cloud over the past five years, ContainerSolutions have been carefully analysing each experience. We’ve identified common challenges faced by enterprises from many sectors, and the ways to overcome or simply avoid them. These tactics became Container Solutions’ four-part process for successful transformation: Think, Design, Build, Run.

The first stage, Think, begins with the Container Solutions Cloud Native Maturity Matrix, an assessment tool for mapping an effective transformation path. The Maturity Matrix investigates nine different areas of transformation, some technical, others cultural and organisational. The results are used to define, analyse, and describe an organisation’s current status and then create a custom roadmap for the fastest—and lowest risk—transformation.

This questionnaire will guide you through a Maturity Matrix self-assessment. It’s a lightweight version of the same tool CS engineers use when performing our in-depth Cloud Native Assessment, a multi-day dive into a company’s current systems, processes, and culture. Even though it’s much less detailed, this basic version will still provide an initial high-level snapshot of where you are right now—and a general flight path for your company’s own transformation.

Next step: After you get the results from our Maturity Matrix, see the back page to get a free deck of patterns cards, and order our new book, to start planning your Cloud Native transformation.


INSTRUCTIONS

How do we assess current organisational status?

First, you will answer a series of questions designed to reveal your company’s current status, from culture to process to infrastructure. We use the answers to draw a point on each of the nine separate axes.

Once all nine areas have been assessed, we then literally connect the dots by drawing a line through each status point. Graphing status in this way gives instant valuable feedback, and provides a powerful visual of your company’s current state.

Next, we use this insight to match your results to typical scenarios that we have observed at other enterprises seeking to migrate their legacy systems and transform into a true Cloud Native entity.

Remember our sample matrix with results from a real-world enterprise Cloud Native assessment?

The results show a company that is functioning largely in a traditional Waterfall hierarchy. Culture, however has progressed somewhat and is taking first steps toward Agile. Perhaps this was in response to advances in their Process, which has nearly reached Agile.


If you answered Yes to questions 1 and/or 3, place your dot on Predictive. If you answered Yes to questions 2 and/or 4, place your dot on Iterative. If you answered Yes to a mix of odd and even numbered questions (or none at all), place your dot halfway along the dotted line between the two.

How individuals in your organisation interact, communicate, and work with each other.

In our company…

1. Project managers coordinate between all the different

teams working on the same project, and the teams have

highly specialised responsibilities.

2. Our development teams focus on achieving small,

defined objectives quickly and then moving immediately

to the next one.

3. A lot of up-front planning goes into documenting each

step of a project before it even begins.

4. Each team contain a mix of members whose different

areas of expertise cover the full spectrum of skills needed

for crafting a releasable increment.

1. CULTURE

Yes No


What you do, and how you go about doing it. How do decisions get made in your organisation about new products to build, or services and features to offer — or how to improve existing ones?

In our company…

1. We have product roadmaps spanning months or even

years into the future. Our releases typically happen every

six months to one year, sometimes even longer.

2. There is pressure to deliver features, fast, and releases

happen on a regular planned basis. (For example, ‘We’ll

Feature X in two months, Feature Y in four months and

Feature Z in six months’—with no deviation from the

schedule).

3. We release large sets of related features all at once as

comprehensive updates.

4. Our releases are usually small-scale iterative changes to

existing features/services.

2. PRODUCT/SERVICE DESIGN

If you answered Yes to questions 1 and/or 3, place your dot on Long-term Plan. If you answered Yes to questions 2 and/or 4, place your dot on Feature Driven. If you answered Yes to a mix of odd and even numbered questions (or none at all), place your dot halfway along the dotted line between the two.

Yes No


How do responsibilities, communication, and collaboration work between teams in your organisation?

In our company…

1. All decisions are made by managers, and teams must

seek permission before changing any part of the project

plan, no matter how small.

2. Applications are developed as several large components,

with one team per component fully and vertically

responsible for the build.

3. We have separate teams of specialists to handle different

areas: design, architecture, security, testing, etc. When

our team’s piece of a project is finished, we hand it off to

the next team.

4. Our teams are mixed: We have developers, QA/testing,

someone with server experience, etc. all in one group. We

don’t talk to other teams very much since our teams are

meant to be self-sufficient and independent.

3. TEAM

If you answered Yes to questions 1 and/or 3, place your dot on Hierarchy. If you answered Yes to questions 2 and/or 4, place your dot on Cross-functional Teams. If you answered Yes to a mix of odd and even numbered questions (or none at all), place your dot halfway along the dotted line between the two.

Yes No


How do you plan and then execute work?

In our company…

1. We do all our planning up front, and then hand off to

teams for execution. Managers handle the collaboration

and communication between our teams.

2. A team will work on one small, defined project and deliver

it in two to four weeks. If a new feature request comes in

the middle of a delivery cycle, we may or may not be able

to add it in.

3. If a new feature request comes in the middle of a delivery

cycle, we have to wait for the next cycle to plan for and

incorporate it.

4. If we can’t coordinate or fix an issue on the last day or two

of a production cycle, we can’t ship—so when a bug or

some other problem pops up it’s hard to do anything more

than a quick fix. (Following up to address an issue in more

depth requires a dedicated sprint so we can focus on it).

4. PROCESS

If you answered Yes to questions 1 and/or 3, place your dot on Waterfall. If you answered Yes to questions 2 and/or 4, place your dot on Agile. If you answered Yes to a mix of odd and even numbered questions (or even none at all), place your dot halfway along the dotted line between the two.

Yes No


What is the overall structure of your technology and systems?

In our company…

1. Our system is very big. Few people understand the

whole thing. We fear the domino effect: If you change

something, you have to be very careful because it could

break something else.

2. Our application(s) is(are) divided into components,

probably no more than five or six, communicating through

networking.

3. When we deliver, everything is delivered together, all

ready on the same day and at a uniformly high level of

quality.

4. The scope of an app in development is defined by

the deployment schedule. Each feature or piece of

functionality is broken down into deliverable chunks that

fit into the schedule.

5. ARCHITECTURE

If you answered Yes to questions 1 and/or 3, place your dot on Tightly coupled Monolith. If you answered Yes to questions 2 and/or 4, place your dot on Client server. If you answered Yes to a mix of odd and even numbered questions (or even none at all), place your dot halfway along the dotted line between the two.

Yes No


How does your organisation deploy software and run it in production?

In our company…

1. We have some simple automation, like scripts, for alerting

large-scale issues and outages in the field. We find out

about many smaller problems from user reports.

2. Our systems have full and continuous monitoring, and our

Ops team spends lots of time checking on alerts. A lot of

time, our system alerts turn out to be nothing.

3. When problems arise, we have to open each server to

understand what happened because we don’t have central

logs or tracing. Then we fix it manually: someone from

Operations logs into a production server and follows a

preset procedure.

4. Some of our system update processes are fully automated

and patches can be applied quickly—but a human still has

to initialise the process.

6. MAINTENANCE AND OPERATIONS

If you answered Yes to questions 1 and/or 3, place your dot on Ad-hoc monitoring. If you answered Yes to questions 2 and/or 4, place your dot on Alerting. If you answered Yes to a mix of odd and even numbered questions (or even none at all), place your dot halfway along the dotted line between the two.

Yes No


How does software progress from your development teams to running live in production?

In our company…

1. We do ‘big bang’ releases that roll lots of changes into

one new version, every six to 12 months. A lot of up-front

planning goes into our next release before any actual

development begins.

2. Our delivery process includes some test automation

and automated build, but outside of final integration.

In an emergency, we can make manual updates to the

production codebase.

3. We don’t like to make changes to our production code,

even emergency ones, because there are so many

dependencies. Change is risky. Once we release a software

version all changes have to wait for the next version

4. roll out.

5. New functionality requests typically can be

accommodated within a few weeks, if they are urgent.

7. DELIVERY

If you answered Yes to questions 1 and/or 3, place your dot on Periodic releases. If you answered Yes to questions 2 and/or 4, place your dot on Continuous Integration. If you answered Yes to a mix of odd and even numbered questions (or even none at all), place your dot halfway along the dotted line between the two.

Yes No


How does your organisation create and then control new infrastructure? How quickly can you deploy?

In our company….

1. Operations team is in charge of provisioning, period. You

have to write a ticket to provision a machine—engineers

can’t self-service.

2. A machine can be provisioned (possibly even

autoprovisioned) in hours, or maybe a day or two, and the

process is fully automated by Ops.

3. Developers write applications, and specify what they

will need to run successfully in production (OS, libraries,

dependent tools). The Ops team manually configures the

production machines to meet the machine dependencies

the Dev team specified.

4. Provisioning is a mix of automation and manual work.

Any task taking longer than a week to provision to VM

breaks the production cycle, so is a nonstarter.

8. PROVISIONING

If you answered Yes to questions 1 and/or 3, place your dot on Scripted. If you answered Yes to questions 2 and/or 4, place your dot on Config. management. If you answered Yes to a mix of odd and even numbered questions (or even none at all), place your dot halfway along the dotted line between the two.

Yes No


Your Infrastructure describes the physical servers or instances that your production environment consists of: what they are, where they are, and how they are managed.

In our company…

1. We have multiple physical servers in our own private

data center (either on premises or co-located). If one of

our servers goes down, we have to manually provision its

replacement.

2. We don’t use physical servers—we have VMs. We also

have some instances in the cloud, which we manage

manually.

3. A data centre failure is just about the worst disaster we

can imagine.

4. Provisioning infrastructure is a mix of automation and

manual work, so a new VM can take a couple of days to

set up.

9. INFRASTRUCTURE

If you answered Yes to questions 1 and/or 3, place your dot on Multiple servers. If you answered Yes to questions 2 and/or 4, place your dot on VMs (pets). If you answered Yes to a mix of odd and even numbered questions (or even none at all), place your dot halfway along the dotted line between the two.

Yes No


DRAW YOUR LINE

1. Use your answers from each of the individual axis questions on the previous pages to draw a point on each of the nine separate areas on the full Maturity Matrix chart. (Remember that it’s OK to place that point halfway between two categories).

2. Now literally connect the dots by drawing a line through the status point marked on each axis.


An organisation can’t undertake a Cloud Native transformation by simply transferring its existing system onto the cloud and keep doing business the way it always has. A transformation is a much more complex process than that, getting more complicated as the process moves forward. It’s not just new technology; it’s the dawn of a new way of working, a new, organisation-wide way of delivering value to customers.

But many companies try to do this very thing. This is known as the ‘lift and shift’ scenario. Typically, after struggling for months to move the old system, and spending possibly a couple million pounds or Euros, an organisation will discover that, yes, it’s got Kubernetes and cloud infrastructure ... and nothing works. Or maybe things are sort of working, but not any faster or better than they did before.

Here are some typical Cloud Native transformation assessment outcomes, each presented with what this looks like as a Container Solutions CN Maturity Matrix graph. Sometimes these assessments were done in preparation for a cloud migration; other times, as triage on a transformation that had stalled or otherwise gone wrong. It is important to note that every organisation’s journey to the cloud will be different; these scenarios represent the big picture, not analysis on a granular level.

In this step, try to match the Maturity Matrix graph you just created from your questionnaire results with these real-world client assessment examples. (Here we are presenting only the four most common scenarios we encounter; however, we have identified over a dozen more). Since every company, and every transformation, is unique, you may or may not find your company’s match.

COMMON SCENARIOS

1. ‘LIFT AND SHIFT’ MOVE TO CLOUD INFRASTRUCTURE


In this scenario we see: A company with Waterfall or Agile culture, architecture, design, and processes that has attempted to ‘lift and shift’ its current system (and comfortable way of doing things) onto the cloud. On the Maturity Matrix, Infrastructure has moved all the way to Containers/Hybrid Cloud while all other categories remain rooted around Waterfall/Agile status.

What will happen: Operating costs will go up. Few, if any, benefits will be gained. Time and money will be wasted: you now have a bunch of expensive, complex tools on top of the same system you always had—but you are not faster or cheaper.

A better approach: Focus on moving all points on the Maturity Matrix to their Cloud Native state. For most organisations this likely means starting with Architecture and Process while simultaneously working to gradually evolve Culture. However, if there are parts of the original system that are stable and seldom changed, these can indeed be moved to the cloud using lift and shift.

The practical solution: An honest and thorough assessment of current state is essential before moving forward in any aspect of a cloud migration. Start at the very beginning of the Cloud Native Transformation Roadmap with Stage One, Assessment, and you will emerge with a clear vision, a high-level architectural direction, and alignment among leaders in the company.

1. MOVING TO CLOUD INFRASTRUCTURE “LIFT AND SHIFT”


2. TREATING CLOUD NATIVE AS SIMPLY A TECHNICAL UPGRADE

This particular scenario can happen any time in any organisation, but most often arises when a company that has adopted at least some Agile practices fails to recognize that moving to Cloud Native is a second true paradigm shift. Instead of being treated as a major and serious change in its own right, the CN transformation is treated as just a bunch of tech-related tasks that get added to the existing development backlog. Basically, this approach treats CN as an updated implementation of Agile—and it doesn’t work.

In this scenario we see organisations make more real progress toward building a CN platform, but they are still unable to deliver software on it. This is because, while they have updated their technology, their organisational culture and processes have not evolved to match. The new platform requires a whole new way of working, but they find it difficult to abandon the ‘good old ways’.


2. TREATING CLOUD NATIVE AS SIMPLY A TECHNICAL UPGRADE

In this scenario we see: The CN portion of the transition gets placed within the scope of Agile coaches and thus gets led by them. And/or the project is handed to an IT team, added to the backlog of their usual tasks. This is a genuine paradigm shift, but Agile sees it as only a simple platform iteration. Install Kubernetes, two sprints, done!

What will happen: This results in CN tools such as Kubernetes, CI/CD (Continuous Integration and Continuous Deployment) and Microservices being treated simply as normal extensions of Agile, which they are not. Cloud Native adds many completely new complexities, and requires a very different approach.

A better approach: This is a major shift for a culture used to a tightly coupled approach where everything is developed in parallel for simultaneous delivery. Doing a contained experiment first helps a Waterfall team understand their baggage from functioning within a hierarchy-driven monolith. It then helps them evolve into a collaborative and distributed Cloud Native way of working.

The practical solution: Take small steps for a gradual transformation. Start by trying out an initial small side experiment that encompasses the major elements of CN: an architecture of containerised microservices communicating via APIs, developed and delivered through CI/CD, and implemented/orchestrated on a fully automated cloud platform. This prototype app can be very basic, but it does need to be functional. Such small experiments are part of step two of Container Solutions’ process, Design.


3. THE GREENFIELD MYTH, or, THE ‘ALL OR NOTHING’ APPROACH

In this scenario we see a Waterfall organisation with a deep legacy codebase—say, for example, a mainframe running COBOL. An enormous amount of work and organisational change are required to refactor any monolithic system into a flexibile, functional Cloud Native one. The understandable temptation is to simply scrap the old system completely in favor of building a brand new one from scratch. A complete greenfield project must be cheaper, faster, and more efficient than trying to work with the existing one, right?

An ‘all or nothing’ attempt—rebuilding a monolith into microservices from scratch—is not always a bad move. There are serious advantages to greenfield development for startup companies, and even for an established one, greenfield can be a great way to go—if you know what you are doing. But most companies don’t. Cloud Native is simply too new. And it’s expensive and unnecessary to replace a monolith if it is actually working pretty well for you.

Rather than starting over, why not keep the legacy codebase in place and build a custom bridge to the cloud? It’s cheaper, it’s faster, and it’s much, much easier.


3. THE GREENFIELD MYTH, or, THE ‘ALL OR NOTHING’ APPROACH

In this scenario we see: Companies whose main codebase is in a deep legacy language that decide it’s time to scrap it and build a brand new Cloud Native system. The result: a stalled (or even failing) attempt to build a completely new system after six months of dedicated ‘all or nothing’ effort. Meanwhile, there has been no development at all on the old system.

What will happen: Confusion, chaos, and a deeply frustrated and unhappy team. You can’t just go all in—assign all your COBOL engineers to shift to Kubernetes. You may as well ask them to fly your mainframe to the moon. A better approach: In many cases it isn’t worth re-architecting a deep legacy monolith to microservices or CN in general as the value might be very low and the cost of change significant. A prime example of ‘if it ain’t broke, don’t fix it’. However, you can still build around it to capture Cloud Native’s risk-reduction and product-velocity benefits in other areas. The practical solution: If you have a strong system that requires few or no changes and it is stable, just keep it. Package it so that it sits on one server and works forever. After that, you design and then create new pieces that talk to the old piece (phases two and three of Container Solutions’ process, Design and Build). Make a tiny greenfield Cloud Native platform and then slowly move one piece over at a time, refactoring and rebuilding your platform as you go. It’s a very slow, iterative, long-term process, not a quick re-creation of your legacy system only now in the cloud (see scenario one, ‘Lift and Shift’). But it works.


4. ‘SPIKING’ CN TRANSFORMATION VIA

AN UNBALANCED APPROACH

This is the most common scenario we see. An unbalanced approach can happen at any point on the Maturity Matrix. When we are called in to help with a migration gone wrong, however, we typically find a mostly Agile organisation that has moved forward in a single one of three areas—Microservices, Orchestration/Kubernetes, or DevOps—while failing to progress in all of the other areas crucial for a CN transformation. The graph shows a single sharp ‘spike’ in an otherwise uniform line. The spike’s axis can vary but the final outcome is the same: the transformation initiative will bog down and is likely to ultimately fail.

This happens when the initiative is started in, and driven from, a single faction in the company: Ops, say, or Dev, or executive management. No other groups are participating, and so the transformation happens only in the area that affects the originating group. They unilaterally proceed with the project doing only what is important from their point of view—without taking the role of every other division into consideration.

Here’s an example: If the initiative started with a push for Kubernetes in Ops, the Orchestration axis leaps ahead of where the whole rest of the company finds itself on the Maturity Matrix:


4. ‘SPIKING’ CN TRANSFORMATION VIA AN UNBALANCED APPROACH

The outcome of an unbalanced approach is frustration among teams, not to mention the investments of time and resources into an initiative that ultimately achieves little.

In this scenario we see: A company has decided to move into the cloud, and adopts one new practice or technology (Microservices, DevOps, Kubernetes) without considering the impact upon all other areas in the organisation. This one area looks like a spike on an otherwise uniform matrix line.

What will happen: These initiatives rarely lead to success because teams very quickly run into all kinds of problems they never considered. Gridlock ensues: they know they have a problem, but they don’t know enough to even begin to understand what to do about it.

A better approach: Senior managers or executive/board leadership needs to intervene and define the CN transformation as a dedicated project that is a company-wide priority. The mandate brings all branches on board to work simultaneously on transforming their particular area of responsibility, while providing all the resources required.

The practical solution: A combination of steps one, two, and three of the Cloud Native Transformation process. The first need is to establish executive commitment to the transformation, including a defined vision and a (high-level) plan for proceeding (step one, Think). From there, step two (Design) protocols establish the architecture and all major design decisions. These are explored through proofs of concept (PoCs) and experiments, so there is buy-in from teams across the organisation. Step three, Build, begins when the optimal transformation path has been identified and it’s time to begin building a minimal viable product (MVP) version of the new Cloud Native platform.


A GLOSSARYOF CLOUD NATIVE TERMS

AGILE: Agile methodology is a widely used approach to project management in software development. It is based on using incremental, iterative work sequences that are commonly known as sprints. Scrum is a subtype of Agile methodology, essentially a specific framework for Agile software development.

CLOUD: Cloud computing, or ‘the cloud’, is a general term for delivering hosted services over the internet. Cloud services are different from traditional infrastructure and platform hosting because they are elastic (users can employ as much, or as little, service as they need at any given moment); sold on demand (by the minute or the hour); and fully managed by the provider (requires nothing but a computer and Internet access). Significant recent innovations have accelerated interest in even smaller enterprises moving to cloud computing. Public versus Private: public clouds like Google Cloud and Amazon Web Services sell services to anyone, and all users share the same resource pool. A private cloud is a proprietary network, usually company-owned, with access limited to specific entities.

CONFIGURATION MANAGEMENT: Specifically, the automation of server configuration and management, using tools such as Ansible, Puppet, Chef, or Terraform.

CONTAINERS: Containers are lightweight, standalone executable software packages that include everything required to run an application: code, runtime, system tools, libraries, and settings. They are a sort of ‘standard unit’ of software that packages the code with all its dependencies so it can run anywhere, in any computing environment.

CONTINUOUS INTEGRATION: Continuous Integration (CI) is a development approach where teams implement small changes and check in code to version control repositories frequently so that the codebase is constantly iterated and updated. The technical goal of CI is to establish a consistent and automated way to build, package, and test applications.

CONTINUOUS DELIVERY: Continuous Delivery (CD) starts where Continuous Integration ends. CD automates the delivery of CI’s small, iterative changes to run on cloud-based infrastructure. Most teams work with multiple environments outside the production pipeline, such as development and testing environments, and CD ensures there is an automated way to push code changes to them. CD automation then performs any necessary service calls to web servers or databases, and executes procedures when applications are deployed.


CI/CD and CONTINUOUS DEPLOYMENT: When integrated, CI/CD together make it possible to implement Continuous Deployment. Continuous Deployment is a key Cloud Native element where application changes run through the CI/CD pipeline and passing builds get deployed directly and seamlessly to fully automated production environments. Teams practicing Continuous Delivery elect to deploy to production on a daily or even hourly schedule.

CROSS-FUNCTIONAL TEAMS: A cross-functional team is where members have different skill sets and competencies, but are working collaboratively toward the same goal. Team members have all competencies necessary for accomplishing the work within the team—so there are no dependencies on others outside the team. In software development this typically means frontend and backend developers, database and UX specialists, QA engineers, and any other role necessary for producing the product/service.

CULTURE: How individuals within an organisation communicate and work with each other. Culture is the sum of the daily actions that you take, your routines. If you talk to people as part of doing your work, you have collaborative culture. Needing to seek permission before trying something new means you have hierarchical culture. If you change the actions, you change the culture.

DATA-DRIVEN DESIGN: Data-driven design describes the practice of developing or improving a product based on things you can measure. Metrics like site analytics, carrying out A/B testing, or surveying users for feedback are all used to make design decisions.

DESIGN THINKING: Design thinking is a human-centred approach to business processes. It focuses on customer problems and challenges as the foundation to producing products and services that satisfy their wants and needs.

DEVOPS: DevOps is both a culture and set of processes aimed at reducing the division between software development and its actual operation. With DevOps, the traditionally siloed Development and Operations teams work together as one cohesive team (or, sometimes, two teams in tight collaboration). The approach facilitates fast and seamless software development while optimising both productivity and reliability. Companies adopting the DevOps model create teams that embrace the entire development and infrastructure lifecycle in their scope of responsibility. See: SRE.


GREENFIELD PROJECT: Greenfield deployment refers to building a complete software development system where previously there was none. In Cloud Native it means not just cloud-based infrastructure but also incorporates architecture, design, process, and culture—basically, starting completely from scratch in every possible area. Greenfield development is often viewed as advantageous because it is free from constraints that can be imposed by a system’s existing networks/infrastructure.

MICROSERVICES: Microservices (microservice architecture) is an approach to application development in which a large application is built as a suite of modular components or services. Each service runs a unique process and usually manages its own database. A service can generate alerts, log data, support UIs and authentication, and perform various other tasks. Microservices enable development teams to take a more decentralized (nonhierarchical) approach to building software. Microservices enable each component to be isolated, rebuilt, redeployed, and managed independently.

MONOLITH: ‘Monolith’ is used to describe a single-tiered software application in which different components combine into a single program, launched from a single platform. A monolithic application is self-contained, and independent from other computing applications, its design based on a ‘batteries included’ philosophy that makes the application responsible not just for one particular task, but can perform every step needed to complete any function. Monolithic apps are huge and complex, and therefore very slow to deliver changes/updates; a typical development cycle is six months to one year.

ORCHESTRATION: Orchestration in general refers to the automated configuration, coordination, and management of computer systems and software. In cloud computing, it refers more specifically to orchestrator tools. The best known is Kubernetes, an open-source system for automating the deployment, scaling, and management of containerised applications. In Cloud Native, orchestration is all about managing the lifecycles of containers, especially in large, dynamic environments. (Dev)Ops teams use container orchestration to control and automate tasks such as the availability, provisioning, and deployment of containers, load balancing of containers across infrastructure, and scaling up/down by adding/removing containers as needed. See also: Containers.


SRE: SRE, which stands for Site Reliability Engineering, evolved independently of the DevOps movement but fits perfectly with it. SRE embodies the DevOps philosophy and then takes it one step further to define an architecture for implementing them. SRE offers a much more prescriptive way to measure and achieve reliability across the full spectrum of DevOps responsibilities. DevOps is a philosophy; SRE is a set of practices. SRE is typically the desired model in very large frameworks, like Google.

WATERFALL: The Waterfall model of software development is based on a logical progression of steps that form the software development life cycle. One follows after the other in strict order, much as a waterfall cascades down from top to bottom. While more Agile methodologies have arisen, causing the Waterfall model to decline in popularity, Waterfall’s sequential process still contains advantages and it remains a common design process in the industry.

Documents

THE CLOUD NATIVE MATURITY MATRIX ASSESSMENT