For seven years, we have worked with mission-critical, defense, and intelligence agencies within the U.S. government to deploy modern software in some of the most demanding environments in the world. From that work, we developed an application networking maturity model. It helps software architects, DevOps, and platform engineering teams drive microservices adoption.
This maturity model defines four stages that organizations pass through on their path to microservices. At the end, they gain application agility, flexibility, and scale without the usual tradeoffs in complexity, security, and visibility.
- Stage 0: Pre-Cloud
- Stage 1: Cloud-Native
- Stage 2: Service Mesh
- Stage 3: Application Networking
Our customers have found this methodology helpful in understanding the operational benefits of each stage. This approach helps solve the technical challenges of moving from one stage to the next. Our customers deliver software faster and reach market sooner. It also provides security across hybrid, multi-cloud and on-premises environments.
Stage 0: Pre-Cloud
A monolith architecture, usually coupled with a pre-cloud suite of tools, consists of several applications running on servers in an on-premises data center. It requires large development teams to integrate separate code changes. Of course, each of these changes require detailed validation before new versions can be pushed out on a quarterly or annual basis.
Slow going
This process is slow and requires considerable effort for developers to update applications. Quality control and assurance are integral to provide success. This has to happen before anything is deployed to production. Upgrades usually take many months and often require specific outage windows.
Lastly, significant planning for data migrations and potential rollback strategies must be considered in the case that something goes wrong. The lightning pace of business today means organizations can no longer afford to hide out in this stage. Those releasing applications sporadically cannot expect to remain competitive.
For example, many industries, such as healthcare and finance, still need to give customers access to data in legacy systems, applications, and databases. However, at the same time, they must figure out how to build modern, user-friendly, customer experiences in new cloud and mobile applications.
Stage 1: Cloud-Native
Most organizations have moved past the monolith stage, introducing cloud-native technologies and microservices as the bridge between legacy and modern applications. They have begun to break portions of their monoliths into separate microservices to accelerate software development. Containers are adopted to package their software. At this point, these organizations have also implemented more agile software development practices. These could include Continuous Integration and Continuous Delivery (CI/CD) pipelines. CI/CD pipelines offer faster application delivery, but can often come at the expense of enterprise security and oversight.
In this stage, individual teams build separate pieces of an application using their preferred programming languages, development frameworks, and logging tools. They often download different sets of open-source tools, libraries, and components. These are then stitched together, requiring expertise and knowledge of how solutions are composed at a granular level. The challenge is how to connect these components to enterprise assets such as databases, ERP tools, services, and core business functions. Teams must do this while they manage one complete application.
Enter the Modernization Pilot
The modernization process usually begins with a pilot application. This pilot may consist 6-12 microservices running in a cloud-native environment, such as a managed Kubernetes cluster. Many organizations in the cloud-native stage have begun implementing Docker and Kubernetes, running upwards of 30-50 Kubernetes clusters. However, most do not have extensive enterprise-wide Kubernetes or cloud-native experience.
Legacy applications sit behind hardened firewalls, where organizations can manage them on servers or virtual machines. However each microservice in a cloud-native environment is a separate networked application unto itself, with limited control, security, and visibility. In fact, the more a monolith is broken into separate microservices, the more surface area there is available to attack. This makes it much harder to meet existing compliance requirements with new cloud-native applications, while auditing, reporting, and proving that Kubernetes is secure.
IT teams are often left frustrated without being able to understand, control, and see what is happening in applications they are managing. This frustration grows with the complexity of deploying decentralized software. Microservices, APIs, and data sources now span hybrid and multi-cloud environments.
Stage 2: Service Mesh
Organizations in this stage begin to evaluate the need to deploy a service mesh. Service meshes provide a de-coupled layer away from the application code. They are designed to control configuration policies, route internal east-west application traffic, and enforce security across an application networking stack. This stack includes connected microservices, APIs, and data sources.
Security is the number one driver for organizations to move from Stage 1 to Stage 2. Because each connected microservice, API, and data source runs in different locations, IT teams must secure the connections between any data or communications flowing between “Application A” and “Application B” or vice versa.
This process is handled with mutual Transport Layer Security (mTLS). mTLS makes sure that all communications are encrypted when flowing between any applications, APIs, and microservices running within the Enterprise. In most cases when considering service mesh, these communications are between applications that are running within a Kubernetes environment.
mTLS, but now what?
IT teams first prove that their cloud-native applications are secure with a service mesh. That mesh has a control plane and a fleet of data planes, with or without proxies. Next, the teams need visibility and control. A service mesh allows them to gain that visibility into application performance and allocate the right resources to important applications. Then they can begin to comb through statistics allowing them to trace and troubleshoot problems as they arise.
DevOps can now work with Application Development teams to see how their applications run. Together they build resiliency and meet SLAs, SLOs, and other metrics. At this point, they are betting that mTLS encryption will be enough to meet security team requirements. They believe they are finally ready to roll out into production.
This is where most companies gets stuck. These organizations realize that in a dev environment, service mesh is not enough. In short, the enterprise needs more than a service mesh to control complexity in live production. It must also manage different clouds, VMs, Kubernetes clusters, and exposed APIs.
Stage 3: Application Networking
To move from Stage 2 to Stage 3, DevOps and platform engineering teams now enter a world of exponentially greater complexity. Decentralized, microservices-based applications in a live, production environment focused on Day 2 operations are much harder to manage at scale.
Organizations at this stage have implemented a service-centric enterprise with many applications connected to APIs and managed data services. Some organizations may have a service mesh and follow modern CI/CD processes for deploying new application changes in cloud-native environments. This may include separate teams working on different parts of an application running on AWS, Azure, or Google Cloud.
However, once an application is ready to go into production organizations need to allow users to access it’s various parts. IT teams want to integrate SSO, Microsoft Active Directory or an independent IAM tool with their service mesh, Kubernetes, and applications. But most struggle to do so.
Identity Management Challenges
This is when identity management, user authentication, role-based access control, and user-tracking audits become barriers to wide-scale adoption. IT teams must grapple with managing an ever-growing suite of third-party, cloud-native, middleware to connect legacy databases, APIs, microservices, and data sources across decentralized applications.
It’s inefficient to have separate AWS admins, Azure admins, database admins, and network admins configure the right settings for different users.
Also, CISOs and security teams need to know what controls are in place. They need to know who has access to which applications, and make sure that the applications are isolated in multi-tenant environments. In addition, they must also prove compliance with security industry best practices across public and private clouds.
Most organizations don’t have the internal experience to manage this level of complexity. Furthermore, IT teams that have implemented service mesh solutions often realize they can’t move their applications to production without a more complete microservices solution. And failing that, they will require a large amount of out-sourced services expertise.
Greymatter Helps Enterprises Move to Stage 3
These are the same challenges the world’s largest defense and intelligence agencies ran into. Their also why Greymatter has spent the last seven years focusing its efforts to build the best and most enterprise-ready application networking platform. Greymatter exists to address the issues Stage 0, 1, & 2 organizations face when moving to Stage 3.
We built an enterprise application networking platform that combines service mesh, API management, and infrastructure intelligence. It helps organizations reduce complexity, secure their systems, enforce compliance, and improve performance in any environment.
We understand that application networking and service-centric enterprises extend beyond Kubernetes. Organizations still use monoliths, VMs, and bare metal. Our platform was built as a bridge to the future. Greymatter is built for enterprises that want the benefits of APIs, microservices, and service mesh now, in months, not years.
We can help, no matter the stage
So, if you’re at Stage 0 or 1, we can help. We can start by helping you lay out your reference implementation architecture in 30 days or less. Here, we will start outlining how to make sure everything integrates. This will help prevent you from hitting roadblocks when you attempt to move from Stage 1 to Stage 2.
If you’re stuck in the mud in Stage 2 or spinning your wheels reaching for Stage 3, we can help. You might be in Stage 3 and find that managing a decentralized environment consumes your platform engineering resources. We can help there too. Our technologists can assess your application networking architecture. And we can implement a model that enables zero-trust security, mTLS authentication and end-to-end encryption in 90 days or less.
Contact us today to schedule your free consultation. First, we will help determine your microservices maturity level. Then we will build a reference implementation architecture to begin moving your organization up the microservices maturity model. Accelerate software delivery and increase speed to market, while providing security today, with Greymatter!