Multicloud Architecture Migration and Security

Chapter 1. Why Multicloud Architecture?

Organizations are increasingly relying on the cloud for the deployment and management of application stacks. In fact, most organizations support many cloud-based applications. According to a 2018 IDG study, 73% of organizations have at least one application hosted in the cloud. Services that used to be managed entirely on-premises, such as the sales process, timekeeping, and human-resources management, now reside entirely in the cloud. At the same time, organizations are moving their own homegrown applications to the cloud. Hosting in the cloud saves on initial infrastructure costs, planned and unexpected maintenance costs, and operational costs. But there are challenges and complexities associated with adopting a multicloud architecture that these organizations should consider.

Organizations need to weigh many factors when selecting a cloud service provider. One of the biggest challenges they face when migrating to the cloud is choosing the appropriate platform. Sometimes, the choice is made for you. For example, some outsourced services work only with certain cloud providers. In other cases, organizations have become locked into using a specific cloud vendor when applications were first moved to the cloud.

Another challenge associated with running a multicloud architecture centers on security. Organizations need to apply a consistent security policy across all cloud platforms that is consistent with the security policy of internal systems. In the end, it doesn’t matter whether a system is onsite in the core of your network; sitting in an Amazon, Microsoft, or Google datacenter; or residing at a specialized hosting provider. The security team is responsible for the system’s integrity regardless of where it resides.

These challenges are certainly daunting, but they are not insurmountable. The goal of this book is to help managers and leaders understand the challenges of migrating to and securing a multicloud infrastructure. In this book, you learn about ways to manage and orchestrate multicloud environments, including some “edge” technologies that are designed to secure and protect your environment.

What Is a Multicloud Architecture?

Cloud architecture is generally broken down into two different types of deployments: multicloud and hybrid cloud. Multicloud architectures, in which multiple services are hosted by different cloud providers, are the most common deployment. In one example of a multicloud deployment, Domain Name System (DNS) services are hosted by one cloud provider, web applications are hosted by another, a helpdesk ticketing system is hosted by a third provider, and so on. This type of multicloud deployment involves multiple cloud providers, each with a standalone function operating relatively interdependently across multiple providers.

Although multicloud deployments might seem straightforward, keeping track of the different capabilities of each vendor and ensuring that updates and policies are correctly applied across all cloud partners can be very challenging. In a multicloud architecture, complexity stems from the process of managing the environment in the context of various shared responsibility models and geographic considerations. This type of architecture also means that each provider is a single point of failure for your organization.

A hybrid cloud is generally considered a combination of a public and private cloud, but this definition has been expanded to mean on-premises and cloud in some contexts. According to the National Institute of Standards and Technology (NIST), “the hybrid cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds).”

Hybrid cloud involves deploying a single system to multiple clouds. For example, rather than deploy a web application to a single cloud provider, an organization deploys it to multiple providers. An organization might decide to use Amazon Web Services (AWS) as the primary provider with Microsoft Azure as a backup provider. Alternatively, you might want both AWS and Azure to be live and alternate incoming requests between the two providers.

We can carry out a hybrid cloud deployment in multiple ways:

Public-private

Part of the application runs on a public cloud provider, whereas backend systems run in a separate private cloud environment.

Active-passive

A service is deployed primarily to a single cloud provider, but a backup of that service is deployed to a second provider. The second provider is activated only if the first provider experiences a failure of some sort.

Active-active

The service or application is deployed to two or more cloud providers, all of which are live and serving content simultaneously based on geolocation information, load balancing algorithms, or a simple round-robin request.

Hybrid cloud solutions are much more complex to deploy and even more complex than multicloud solutions to manage on the backend. However, the uptime benefits and the lack of a single point of failure more than offset the costs incurred in terms of complexity. These hybrid cloud solutions also take more upfront planning prior to the initial deployment so that teams can understand how the data will be served from each provider and what the required investment will be to present a homogeneous experience to end users across all platforms.

Benefits of a Multicloud Architecture

There are a number of benefits to a multicloud architecture. One benefit is related to cost. Maintaining servers and infrastructure on-premises requires large and ongoing capital investment, whereas deploying in the cloud significantly reduces the costs. Beyond capital expenses, a multicloud strategy enables organizations to invest wisely, on a per-project basis, in the cloud provider best suited for a particular service. AWS might make the most sense for BaaS, whereas Google Cloud Service might make the most sense for deploying a human-resources application. Maintaining multiple cloud providers means that you will be able to choose the best one for each purpose.

Beyond cost savings, there are other benefits to a multicloud platform, including the following:

• Freedom from cloud vendor lock-in

• Infrastructure security and resilience

At first glance, there appears to be a lot of similarities between cloud providers in terms of features and pricing, but a closer inspection can reveal many differences. If your organization is locked into a single provider, you won’t get a chance to explore those differences. For example, two providers can offer a similar service, but one includes it as part of the base pricing; the other offers it as an add-on that can result in unpredictable monthly costs. Some providers offer capabilities in only certain regions or might not even offer a presence in a region that is important to your organization. Preventing provider lock-in means having the freedom to deploy applications where you need them, in the most optimal manner, whether that is a technical, performance, or pricing optimization.

A multicloud solution also provides better infrastructure resilience. Today’s organizations demand high availability (HA) for the applications and services on which their customers and employees depend. The slightest interruption in availability can cause cascading disruptions and associated revenue losses. The idea of 99%—or even the much-talked-about five nines (99.999%) uptime—is an antiquated concept. Customers and employees need to know that they can reach your web applications 100% of the time, no matter what else is happening on the internet. Multicloud architectures can deliver the resilience and uptime that organizations require.

Case Study

In late February 2017, a series of cascading failures caused one of the largest cloud providers to be unavailable for four hours. Four hours might not seem like a very long time, but that was four hours that Netflix, Spotify, Pinterest, and hundreds of other sites were not available to anyone. The outage did not just affect consumers. Many functions of Slack, a popular tool used by organizations for inter-office communication, weren’t available during that time, as well, leaving many corporations unable to communicate internally.

The problem was restored as quickly as the cloud provider’s engineers were able to fix it, but the affected companies fielded complaints from angry customers for days after the outage occurred. Outages like these can potentially cause millions of dollars in lost revenue.

This illustrates the inherent dangers in relying on a single cloud provider for hosting your web application. Even the most reliable providers will occasionally experience outages and their outages impact your customers. A diversified cloud presence allows an organization to better weather these types of outages and it means their customers will see little to no impact.

Modes of Distributing Workloads Across Multiple Cloud Providers

Each type of architecture deployment has its pros and cons. Often, the type of architecture used depends on the kind of application being deployed, but it can also depend on budgetary concerns and the maturity of the organization making the deployment.

None of the modes discussed in the subsections that follow are inherently better than the others. The best choice is largely dependent on an organization’s specific business requirements, internal processes, and standards.

Active-Active Versus Active-Passive

Active-active and active-passive architectures are all about ensuring HA. They’re designed to ensure that customers or employees in any part of the world can access web applications quickly, with very little latency. These architectures also ensure that if one cloud provider experiences a failure, end users will not notice, because the failover will be seamless.

Figure 1-1 provides a simplified example of what an active-active architecture looks like. A web application is deployed across multiple cloud providers, each with a load-balancing service enabled in front of the application. The load balancers ensure that the service behind it is up and running and not overloaded with traffic. The load balancer then selects the best server and directs the incoming request to it. If one cloud provider becomes unavailable, the other provider is able to shoulder the traffic load.

Figure 1-1. Active-active multicloud architecture

There are other ways to enable this kind of load balancing. Some organizations use advanced DNS services to replicate this kind of architecture.

Figure 1-2 shows a similar active-passive multicloud architecture. This solution has the same high-level architecture. The difference is that the systems in the second cloud provider’s datacenter remain dormant unless there is a failure of some sort at the first cloud provider. That failure could be physical in nature, such as server crashes or interruptions in network services. But it could also be a threshold failure in which, for example, the site experiences a significant spike in traffic because of an advertising promotion or it begins to trend on social media.

Figure 1-2. Active-passive multicloud architecture

In an active-passive architecture, the backup site is “hot,” the infrastructure is online and listening, but no traffic is directed to that cloud provider unless the failure occurs. Active-passive architectures are more cost-effective than active-active multicloud environments, but there are a number of technical complexities that need to be taken into consideration. First and foremost, the infrastructure must be tested regularly to ensure seamless failover in the event of a failure at the primary site. The infrastructure of the passive site must be treated as if it were live. You can take advantage of the fact that you have a fully functional replication of your website or web application by testing new patches and configurations on the passive site before pushing them to the live site.

Public-Private Multicloud Architecture

Up to this point, we have been discussing public cloud infrastructure, but cloud infrastructure can also be private. This can be a nonpublic instance set up in a traditional cloud provider, such as Amazon or Google, or it can be a cloud instance set up in your own datacenter or colocation facility.

Private cloud infrastructure is usually designed to host highly-sensitive organizational information. A private cloud instance might hold customer data, employee information, or other sensitive company documents. Access to this type of infrastructure is usually restricted and requires virtual private network (VPN) credentials or, at a minimum, firewall and proxy rules that prevent outsiders from accessing the data contained in the private cloud instance.

However, there is a third configuration option in the case of private cloud architectures. That is the hybrid public-private cloud. Figure 1-3 presents this design in which some information from the private cloud needs to be accessible to a larger audience or even publicly accessible. In these cases, the architecture is split between servers in a public cloud environment and servers in a private cloud environment with a firewall or other security device restricting access to only that information that needs to be shared with the public cloud space.

Figure 1-3. A public-private hybrid multicloud infrastructure

This can be a tricky configuration because there is the potential to expose sensitive data. For example, there have been multiple Amazon Simple Storage Service (Amazon S3) bucket data exposures within the AWS cloud. This doesn’t mean that you shouldn’t deploy hybrid architectures like this. In fact, they are becoming increasingly common as more data becomes available to the public. What it does mean is that security needs to be considered as part of these deployments from the start of the planning, something that we discuss further in Chapter 3.

Trade-Offs

Although the benefits of multicloud architecture are myriad and discussed in detail throughout this book, it is important to head into a multicloud strategy with eyes open. There are a number of trade-offs involved in migrating to this type of architecture, and some organizations might not be prepared for a multicloud world. There are three potential pitfalls that organizations need to be mindful of when considering a multicloud strategy:

• Increased networking complexity

• Staying abreast of changing public cloud product offerings

• Development agility

Let’s explore these trade-offs in detail so that your team will be armed with the information it will need to make the best decision.

Increased Networking Complexity

Multicloud deployments, by their very nature, are complex. This complexity doesn’t just apply to the networking infrastructure you employ or how you manage servers and databases. There are vagaries of each cloud provider (such as interfaces, controls, and limitations of the platform) that you need to consider as you plan your strategy.

But the primary difficulty is in the networking stack. Anyone who has worked as a network or security engineer for any length of time has had that “Oh, s**t” moment in which part of the network is accidentally knocked offline. Just imagine a mistake that takes down a worldwide infrastructure deployment across multiple datacenters. For example, in November 2018, a Border Gateway Protocol (BGP) misconfiguration at a Nigerian ISP resulted in many of Google’s services being unavailable to much of the world for more than an hour.

Correctly designing the network infrastructure in a multicloud environment is critical. Proper multicloud design involves DNS management, load-balancer configuration, server redundancy, database replication, and firewall rules that allow this traffic to flow freely across multiple providers while not allowing unauthorized visitors access to sensitive data. Of course, this design is not static; it is a living document that must be constantly updated and shared with all stakeholders, including your cloud providers, every time a change is made. If you do not keep the documentation current and regularly share it, one team could make a change that interferes with another team’s change and crash the entire system.

Again, the benefit to doing this correctly is an unprecedented level of resiliency and uptime that would be almost impossible to replicate using your own datacenters. Even if you could, the cost of doing so would be daunting.

Staying Abreast of Changing Public Cloud Product Offerings

Many organizations are interested in deploying applications in a multicloud architecture because those organizations are maturing and eager to adopt newly available technologies. As organizations mature, they’re able to take on more complex projects, and their systems become more intricate.

As your organization is maturing, so is your cloud provider. This means that there are often new services, pricing structures, and capabilities being offered by cloud providers and their competition. It is important to understand what new features are available, especially if these new features can reduce costs. After all, cost reduction is the primary driver for moving services and applications to the cloud.

It is a good idea to schedule quarterly meetings with your cloud provider, usually with a technical account manager (TAM). The TAM will review your account and go over usage with your team. TAMs also keep you abreast of any new services that might be relevant to the organization. You might find during these meetings that it makes sense to switch some services from one provider to another to save money. Many cloud providers offer their own cost analysis tools that you can use to look for cost savings or get a projection of costs before you deploy a new service.

How do you find out about new services being offered by cloud providers that are not part of your current deployment? Most cloud providers give you the option to review services on their website, and of course, a sales team is always happy to call on you. But those options take time, and it’s still possible to miss out on a new service that might be a good fit for your organization.

Another option is to rely on updates from your own team. Cloud providers often offer certification programs for your engineering team. This gives your staff added insight into the services available through the cloud provider and helps them stay abreast of the latest offerings.

Many organizations turn to Cloud Service Brokers (CSBs) such as Bluewolf, Jamcracker, or Cloud Foundry to help identify cloud providers that deliver the right services at the right price. CSBs have experience with a wide range of cloud providers and have worked with other customers, often with needs similar to yours. This extensive experience empowers them to help organizations find cloud services that you might not have previously considered. CSBs can make the process significantly less painful, and they can help organizations get up and running in a multicloud environment quickly.

Development Agility

The last trade-off in considering the move to a multicloud architecture is development agility. A multicloud architecture requires the ability to create code that can run on multiple cloud providers’ platforms, ideally with no changes to the code from one provider to the next. Development standards within your organization help take care of this, so even if the code base is a mess, each provider can run that mess without different code bases.

Moving an application to a multicloud architecture might require your team to revisit application code. The code will need to be cleaned up and tested across your cloud providers to ensure that pushing out updates won’t create problems that will make one of the cloud instances unavailable. But it is more than just editing your code; there are other tasks that you need to complete, such as making sure your provider has the libraries, language compilers/runtime, and server versions available in their repositories for whatever containers you are running. A good example of that is the Java Development Kit (JDK)—you might be at the point at which you can install only an open-JDK version. Another example is that you could have a version of Apache Tomcat that runs a significantly newer servlet specification.

Another problem could be that you are stuck with an old system that is part of your stack that requires something old that you cannot get from a cloud provider, like an older, unsupported relational database. This can cause expenses related to the time it takes developers to plan that upgrade and data migration, and unexpected license costs. None of this would be code cleanup, but it is necessary to factor in the time and cost when making the move.

Development agility is about more than just clean code that can run across multiple cloud environments. It also means adapting to the reality of more frequent updates to the code base. It means updating your code multiple times a month or week instead of a couple of times a year. The development team also needs to be able to rapidly write and test new security patches and deploy them quickly without taking the application offline. Truthfully, this is already a development reality, and being in the cloud to do it is not a requirement for this type of development process. Agile development is how a lot of businesses operate, irrespective of where the application resides.

Given that the Agile development process is the new norm, what changes for most organizations when migrating to a multicloud infrastructure is neither the code nor the development cycle. It is the DevOps process and the Continuous Integration (CI) tools that run DevOps. You now have to package, deploy, and run automated tests on multiple cloud providers. And maybe one app is on just one cloud provider, but another application that needs the redundancy is on multiple cloud providers. You are going to want your development cycle to automatically provision and deploy to the appropriate place. And your local development environment likely isn’t a cloud provider (although it could be).

Evaluation

If you have read this far, you might be asking, how do I determine whether my project and organization are ready for multicloud? It is not hyperbole, or even controversial, at this point to state the future of most IT projects will be in the cloud. The benefits of cost savings, resiliency, and new feature enhancements that organizations realize by moving to the cloud are too great to ignore. Moving to the cloud allows an organization to focus on its core competencies instead of managing a datacenter.

But there is a difference between moving to the cloud and moving to a multicloud or hybrid cloud environment. Let’s take a closer look at how to evaluate which strategy is right for your organization.

Weighing the Pros and Cons

As with any business decision, it is important to look at the big picture, ignore the hype, and weigh the pros and cons of moving to a multicloud environment.

You can begin by examining where the application sits now. Is it hosted in a datacenter managed by your organization, colocated, or is it already hosted in a cloud provider’s datacenter? Making the jump from a locally hosted application to one that is hosted in multiple datacenters around the world might be too much of a jump (not always, but for many organizations it is). Most organizations start by moving their application to a single cloud provider first. This allows the organization to better understand the experience and the challenges associated with cloud migration. For example, the organization might find that its application code is not as portable as it once thought. After you have experience working in a cloud environment, the jump to a multicloud architecture is easier. (Note: We didn’t say that it will be easy, just easier.)

It’s also important to determine how much control your team is willing to surrender to the cloud providers. Cloud providers offer a range of services from the most basic, in which the cloud provider simply offers hardware and a range of IP addresses, all the way up to a fully managed service. The service you choose is also a budgetary matter. The more cloud provider services you take advantage of, the greater the costs.

And of course, all of this has to synchronize across multiple providers. For example, in a fully managed cloud environment, it’s important to know how quickly your provider installs patches. You don’t want to have half of your servers vulnerable to an exploit weeks after a patch is released, or have systems stop working because the code depends on a specific library that has been updated on one provider but not another.

It is important to fully document code and dependencies prior to moving to a multicloud environment—and you must demand the same from your cloud providers. You need to fully understand the services the organization is using, what the cloud providers’ patching cycles are, and how to get support if something goes wrong. You also need to share that information with your team so that everyone knows the limitations of each provider and is empowered to open support tickets.

Designing for a Multicloud Infrastructure

Moving to a multicloud architecture often means redesigning your application to accommodate a more complex networking and infrastructure environment. As with other documentation, this requires careful planning and assistance from the cloud providers themselves when possible. Many cloud providers have architects on staff who can help answer any questions from your team. They can also offer tips to make the migration process smoother. Remember that CSBs often have architects on staff who can advise organizations on different aspects of various cloud platforms.

Cloud architects are a valuable resource, and for many organizations, it pays to have one on staff. The architect could be an outside hire or a person who is already on staff who has been trained on the cloud platforms that the organizations intend to use. The advantage to having a cloud architect on staff is that you will have someone who knows and understands your application in a way that an outside consultant will not. On-staff cloud architects are empowered to give a more accurate assessment of what needs to be changed in order to maximize the success of the multicloud migration.

Conclusion

Migrating applications to a multicloud architecture will increase resiliency while saving your organization money in the long run. But multicloud migrations come with challenges and short-term costs. Before jumping into a multicloud infrastructure, it is important to take a step back and understand the maturity of your application and your team, and to make sure the organization is ready for the complexity of a multicloud deployment.

After completing an internal assessment, the next step is to understand which providers will meet your needs and what their offerings are. Then, it’s time to design the architecture, working with a cloud architect whenever possible. This is also the time to document the new design for your application and make any changes needed to support the new architecture.

Finally, understand that this is not a “set it and forget it” process. The cloud provider is constantly changing, and it is important to stay abreast of the latest cloud provider offerings. If necessary, you can use a CSB to help you find the best match for the cloud services you need.

Multicloud is the future for most organizations—and the benefits outweigh any initial pain associated with the migration. But as with any business decision, it’s important to properly plan the migration and to use a realistic timeline.

Chapter 2 discusses orchestration management in a multicloud architecture. We revisit some of the challenges discussed in this chapter and review ways to effectively manage the migration process and the ongoing maintenance of a multicloud architecture.