With the growing adoption of container and microservice-driven environments, it’s important not to get too excited and potentially throw yourself into a transition that leads to a disaster. While both Docker and containers have carved out a significant space in the industry, moving to containers is tricky and requires significant planning. In addition, there are still quite a few concerns about maintaining visibility on applications, and some teams hesitate because of them.
Abby Kearns of O’Reilly wrote a wonderful research-based article detailing container benefits and challenges as viewed by IT decision makers. Findings indicate that monitoring is viewed as the second greatest challenge in adopting container technologies, behind only container management.
Containers, in general, have so many moving parts that they often require far more forethought into how they’re monitored than traditional virtual machines. Plus, monitoring becomes more complex during the actual transition, and losing visibility on applications can be catastrophic. So we created a guide to help provide the tools needed to ensure that a team and monitoring setup is ready for any transition of existing applications or buildout of new containerized microservices.
There is no one single use case for containers, so for the purpose of clarity we’re going to use a particular use case as an example, showing both a transition from virtual machines to a simple container environment and a containerized microservices environment for an eCommerce website. Our eCommerce example website supports a professional sports franchise, with its variety of online revenue streams.
This environment uses a set of webstore applications to handle store inventory, payment collection, tax calculation, shipping calculation, seat selection, and any other needs for their webstore. These applications are all-encompassing, each performs a multitude of functions and no single function is separated from the application which performs it. While this example is rather simple, the concepts discussed in the guide will scale to more complex environments.
While this environment works for the company, there are many reasons they might decide moving to containers is the right option for them. This brings us to the first step in our guide:
Think about your goals for moving to containers
As with any project, start with a fundamental goal assessment. Why are you moving to containers (beyond them being a trendy technology)? Is your main long-term driver of adoption reducing expenses or increasing development speed? Who (end users, DevOps team, product group, etc.) will benefit most?
Answers to these questions will help frame your architecture. Most often, you will choose between lifting and shifting existing applications into containers or developing or reconstructing applications in a containerized microservices environment. This is how each of those environments will look for our example eCommerce website:
Each environment requires a different methodology to maintain visibility. A simple container environment is going to be more like a traditional environment with a bare metal server and virtual machines since the applications are simply “lifted and shifted” into containers. On the other hand, a containerized microservice environment is going to require a whole new way of thinking.
How do you plan to architect your environment?
How you structure your container environment makes a difference in how you should start your transition and monitor it. Containers have the ability to run a host of newly launched microservices and dynamic, ephemeral apps powering end user experiences designed by product teams eager to take advantage of these new tools.
While a more complex structure is possible, many teams use their new platforms to drive preexisting applications to a higher performance level. Simply “lift and shifted” into the new environment, these applications remain the same, but are granted flexibility that virtual machines can’t necessarily provide.
Between on-prem and cloud, and bare metal, VMs, and containers, your architecture is fundamental to how the transition will work both for your development team and end user experience.
Below, we break down two different transitions this eCommerce website could make from virtual machines to containers and discuss some of the things you should consider before deploying in either of these environment types.
Breaking down each transition
Moving from Virtual Machines to a Simple Container Environment
If you are looking to lift and shift your existing apps from virtual machines to a simple container environment, your approach and thought process before and during your transition is going to be different than moving into a microservices environment. These transitions can seem similar at first, but there are nuances to each that make them different enough to look at them as two different strategies.
First, let’s break down this “lift and shift” method. In this situation, the apps are simply moved as they are from the virtual machine to a container, allowing developers to effectively use the container as a lightweight virtual machine. The eCommerce application remains and so does the architecture of the environment. This application now has the flexibility to scale up or down as necessary. It’s a practical way to begin working with containers before testing more complicated environments using microservices.
A simple container environment also creates consistency between development, testing, staging, and production environments. Having a consistent environment provides a lot of benefits to the development team when they are working on testing or staging by limiting variations between testing and production.
Which applications and structures will you be moving to containers?
Of the applications you intend to move into the new environment, figure out which apps you can’t live without and transition those last. Transition gradually if you can. Start with the least critical piece of infrastructure to help get used to your container platform and orchestration tool before moving more essential infrastructure into the new environment. This limits potential failures caused by human error. Think of it as a practice run.
For example, apps that are only used in limited cases, and are not as critical as a database or an eCommerce website’s payment application, would work well as testers for the new environment.
We also suggest that your monitoring infrastructure is in place before you begin moving other systems into the container environment. Even if you don’t have essential parts of your infrastructure in the new environment, having critical visibility will help you iron out any issues before you move more important structures.
For example, when monitoring a Kubernetes deployment with Panopta, you would set up your server agents and Onsight collector in the cluster before moving any systems into it. Our Kubernetes support, which is currently in private beta release, monitors the most essential parts of your cluster, including metrics at the cluster, service, node, pod and container level. The server agents keep tabs on fundamental system data within your containers and the applications that are running there. The Onsight collector both sends data out of your clusters for collection and works in conjunction with the Kubernetes API.
The Panopta public monitoring probes also check the cluster from the outside to ensure its availability. Having visibility into your environment is essential, so look carefully into what your monitoring service can offer for a containerized environment, even a simple one.
When you and your team are comfortable with this cluster’s reliability and a monitoring framework is in place, you can transition other components on your application list.
Account for any new apps or microservices you are adding to your environment
In addition to the existing applications you plan on moving to containers, you probably have some ideas and use cases from colleagues for great new outputs and high-return opportunities from container adoption. Which new products, features, and end user experiences can be provided more effectively? How will container-based services support these?
Your answers will help you further address the additional requirements new apps impose on visibility, and how these help shape your container stack.
Microservices are useful even in contexts in which your primary goal is to lift and shift existing applications. You might have apps that include many moving parts and functionality, some of which might need to be updated more frequently than others. It’s possible, for the sake of keeping a particular application function up to date, you might want to break it away from the rest of the app’s functionality and structure it as a set of microservices so you can more easily access it and make changes. A shipping cost or tax application is a good example of a function an eCommerce website might want to move to a microservice since they’re inherently more dynamic than product prices.
Including microservices or new applications will add a layer of complexity and make maintaining visibility, understandably, more complicated. Account for any new items you add to your new environment and monitor them more closely during your transition. It will prevent or help diagnose any incidents that come up.
Moving from virtual machines to a containerized microservices environment
As with transitioning to a simple container environment, moving from virtual machines to a containerized microservice environment is going to require answering some specific questions before you start your transition.
Again, it’s important to break down this method of using containers. In our eCommerce example, rather than working with apps that are all-encompassing, microservices allow a team to break down each of an app’s functions into individual parts called services and use a separate page rendering service to assemble the necessary components for the user. This allows development teams the ability to flexibly update different parts of the app without disturbing the rest of the functionality. At the same time, microservices make it challenging to find issues when they come up, and visibility becomes even more difficult to maintain.
What functionality is essential to your infrastructure?
Before you begin a transition to microservices, it’s important to sit down and make sure that you will be able to maintain all of the important functionality you have in your current environment in the new one. As mentioned before, transitioning gradually is going to help prevent issues caused by human error, but it can also help you make sure you maintain the functionality you need.
In eCommerce, when you are trying to slowly transition your storefront into an environment driven by microservices, sit down and list the essential functions of the applications you currently use. This will give you a better picture of the services you’ll need to convert, for example, tax calculation, your shipping engine, inventory management, and so on. Everything you need to build the storefront on the user’s screen will need to be available to the page building service.
Planning for these individual parts ahead of time will both help during the transition and later, once you have completely moved away from your old architecture.
Monitoring container resources in case you need to scale up to keep your microservices running optimally will become a priority in a microservice environment. Microservices make root cause analysis more difficult and will fundamentally change how you’re monitoring your environment. Be prepared to implement those changes before beginning your transition.
What will your hybrid environment look like?
Like most transitions, it’s common when moving to containers from a traditional virtual machine environment, there will be a period of using both. During the time that you are within this hybrid stage, even if you plan to ultimately move everything into a single environment, you’ll need to increase visibility on both environments.
For example, if you do not have adequate memory & CPU capacity available in your containers, and your Docker instance is not adequately configured to prioritize everything that you’re running, you risk Docker shutting down capacity-hogging apps on its terms. As container environments are very dynamic, you need a monitoring solution to prevent unforeseen disruptions.
Similarities between the two types of transitions
Last, we wanted to touch on some things that will come up in both transitions. There are big differences in complexity between these kinds of environments, but there’s also some basic knowledge you’ll want to have regardless of which type of transition you’re going through.
Once you know how you will architect your environment, it will continue to shape the answers to these questions as you start and continue the process. For ease of understanding, we are going to continue using our eCommerce example.
Here are some of the more general items you might want to consider when moving to containers, whether you’re moving to a simple container or containerized microservice environment:
Decide which infrastructure to transition first.
Once you have decided which applications you plan on moving to containers first, you should put together a list of applications or functionality and then put it in order of least to most important. To help you do this, below is a list of questions you might want to ask yourself about each application.
- What systems does that infrastructure rely on?
- What systems rely on that infrastructure?
- Which users rely on that infrastructure?
- What needs to be put in place to make sure the rest of your infrastructure can still reach the services/apps that run there?
Planning on an individual level for each application, or in the case of microservices each function or application, will not only help your team get used to working within the container management system but also help you understand what transitioning your more important infrastructure requires. As we said previously, you can treat the first moves as a practice run.
Who needs access to your environment?
In addition, you’ll need to keep in mind who is going to need to access not only the new environment but also the old one during the period that they’re running concurrently.
Your development team will largely be working within the new environment, while users in other departments are experiencing issues accessing the old systems. It’s possible that upon moving some functionality to your new environment that you begin to find issues in your previous environment that you didn’t expect. All of these are natural parts of a transition, but you can minimize issues by mapping out these needs beforehand.
Is there anything you don’t want to transition to containers?
Containers are great due to their flexibility and resilience but migrating your entire infrastructure to containers might not be possible. It’s important to think about what parts of your infrastructure might stay on traditional VMs, for security or budget reasons, and how they will relate to the new containerized environment and apps.
In the eCommerce example, an inventory application is a more specific example of something you might want to migrate after a few test runs. If users can’t view your inventory, they’re not likely to buy anything from your storefront at all.
Another, more general example of something you might not want to move is your database. Even as microservices advance to include databases for individual services, many teams hesitate to commit to this type of deployment. Reasons range from security to the ephemeral nature of containers, but it’s something you may want to think about as you move forward.
How will your containers share session data?
If an instance only exists for five minutes, you’re going to need to consider where you will track the sessions and other key data elements for that instance and how you will maintain visibility on it as soon as it appears. This isn’t dissimilar to the challenges that monitoring companies were grappling with when going from bare metal to cloud environments where virtual machines had autoscaling.
Trying to keep track of that data is more complicated in a containerized environment due to the lifetime of instances being so short. Keep in mind that your monitoring should account for this.
Finally, how will you architect your monitoring?
We talked quite a bit about the importance of monitoring to maintain visibility in hybrid environments in our previous post, and we’ve mentioned it in this post as well, but it’s worth repeating since it is so essential. The health of your containers will require robust monitoring and how your monitoring is architected will depend on the type of container environment you’re building.
Forming a strategy around maintaining visibility as you move forward can save you a massive headache. We’ll give a detailed view of what an example container monitoring setup can look like in the next post.
So don’t miss our last article in this series, Architecting your Monitoring to Maintain Visibility during a Transition to Containers.