cloud native architecture

Are your current systems bogged down by vendor lock-in? Maybe your company is starting down a software modernization path with a goal of becoming cloud-native? As we move away from vendor-plagued solutions of the past, we may be surprised to discover a new kind of vendor lock-in with modern, cloud-native solutions. When crafting a cloud native architecture strategy, here’s what you need to do to make sure you stay aligned with your goals and keep your cloud software from becoming your new ball-and-chain.

What is a cloud-native architecture?

While cloud-native software may not be completely analogous to core systems running on a mainframe, the investment decision still looms as large as a room full of towering business machines. When describing cloud-native development, you sometimes find other related software terms lumped in: Agile, DevOps, CI/CD, microservices, etc. At its core, being a cloud-native tenant has more to do with how you rely on cloud services to deploy and host your custom applications. Being cloud-native implies far more than just “run it in the cloud.” According to the Cloud Native Computing Foundation (CNCF), it involves reaching a degree of automation that allows change to be delivered efficiently at great scale. For example, an often-cited example of cloud-native success is Netflix, which deploys hundreds of times per day for nearly a thousand services in production.

Understanding your options

Your current hosting landscape may be in three general cloud situations today: mostly on-prem, Platform as a Service (PaaS), or Software as a Service (SaaS). Getting from mostly on-prem to cloud-native in a relatively short time will likely result in more coupling to cloud provider services and frameworks. On your journey, you’ll strike a balance by making deliberate choices. For instance, choosing between relying on the ease of vendor-managed solutions found with SaaS or PaaS and relying on your own organization to manage your systems via IaaS. For compute, you may choose a vendor-managed Kubernetes solution or a hosted serverless platform like AWS Lambda or Azure Functions. These choices have advantages relative to elastic capabilities, but the strategy to avoid cloud provider lock-in requires falling back to self-managed orchestration with Kubernetes. Even more imposing than compute: The choice of a cloud-native data solution can be costly to get wrong. You may gravitate to a vendor managed relational database like Azure SQL Server based on past on-prem experience. If you realize the pricing doesn’t suit your usage or your DBAs miss features like data auditing or database snapshots, then your experts must deploy SQL Server to an IaaS VM to manage along with storage.

Questions for avoiding buyer’s remorse

Similar to the buyer’s remorse you may experience with a vendor-based system, cloud-native systems can cause angst if not aligned with your own business goals and needs. Some things to assess:

  • How much scale do you need?
  • Will your systems that run on dozens of servers today demand the capacity of hundreds or thousands of servers tomorrow?
  • Does your business require legal, regulatory, or privacy standards that some cloud providers maintain across the majority of their products and services?
  • Do you have security expectations from customers that require data and network segregation?
  • Have you identified big data and AI opportunities for your business to leverage?

When aligning your cloud strategy with your answers to the questions above, don’t forget to consider a private cloud, like those running Red Hat OpenStack or Cloud Foundry. When competitors adhere to open-source standards like those in OpenStack, cloud provider lock-in becomes less of a concern. However, open standards apps and services often require more effort to integrate and maintain than canned cloud provider SaaS solutions. In your business, you may have significant assets in your own data center. How does the effort of converting your data center into a cloud-native environment compare to public cloud adoption? Can your operations team allow deployments designed with Infrastructure as Code (IaC), thus treating those costly pets as cheap cattle?

The role of DevOps in cloud-native architecture development

How your developers blend DevOps into their new cloud-native skillsets impacts the lock-in of your new systems. For example, developers who rely on public cloud serverless frameworks like AWS Lambda for computing scale have to code into the solution and are boxed-in by Lambda features. Hands-on use of AWS EKS, on the other hand, should not require changes to your code. For some developers who missed PaaS cloud design, the introduction of SaaS and Infrastructure as Code (IaC) is a generational leap forward in their careers. The “Twelve-Factor Application” principles provide some clear guidance for designing cloud-ready applications. But we also need to consider carving up service boundaries with high-frequency releases in mind. That is, you need to make sure you’re building loosely coupled services—and this time, we mean it (a.k.a. microservices).

According to the Cloud Native Computing Foundation’s 2019 survey, the top challenges of cloud-native development are: cultural changes with the development team, complexity, and lack of training. To meet your business goals with a cloud-native approach, developers must take advantage of the benefits of containerized applications, serverless hosting, and service mesh infrastructure. The monetary cost of implementing a cloud-native system is directly in the hands of your DevOps team. This is a relatively new responsibility for some developers, for whom deployments had little impact on hardware capacity planning in the previous generation of system design. In addition to training and architectural guidance, DevOps teams should leverage IaC self-service sandboxes to learn and grow their cloud-native skills.

Look before you leap

The leap to a cloud-native architecture can be transformative in many ways for your organization. You can avoid undesired cloud-provider lock-in by understanding what balance of control you need on your containerized applications and data storage solutions. Weigh the investment of being a cloud-native tenant against the benefits of meeting your business goals while making a generational leap forward in your technology, skills, and development culture.

Contact an expert