Get Hands-On Experience with BoxBoat's Cloud Native Academy
Resolve to Migrate Off of Swarm this New Year
by Jesse Antoszyk | Tuesday, Jan 14, 2020 | Education
It's the New Year, a time for tidying up your life and your infrastructure. This sometimes means saying goodbye, and as much as we love Docker Swarm, it may be time to think about our adieus. We recently wrote about the 2 year timeline that Mirantis has outlined until they cease supporting Docker Swarm. For some, this may sound like a long time, but a platform migration, especially at scale, requires careful planning and execution.
While a shift in platforms may seem daunting, the time to start thinking about this is now. In this article we will be discussing some of the tasks required for a successful migration. At BoxBoat, we have worked with many companies on their containerization and orchestration journey. If you are looking to move from Docker Swarm to Kubernetes, we have experts in both who can help you on this journey.
So what should we be considering? Below is a general guide of what items we may want to be thinking about. It is by no means comprehensive and should be adapted to fit your particular organization and needs.
Kubernetes is a wonderful, but complicated beast. It has a flourishing ecosystem rife with innovative ways to solve organizational problems. However, to take advantage of this ecosystem, management and development must understand what is possible with Kubernetes and there must be a strong organizational drive to move to Kubernetes. Knowledge of Swarm may give you a general understanding of Kubernetes, but the possibilities and scope are broader in Kubernetes.
Training a core group of developers, security personnel and operators in the Kubernetes platform and workflows is critical for a smooth transition to the platform. Training is a great place to start because it can inform our planning and give realistic expectations as to what our migration will involve. BoxBoat provides expert training in Kubernetes and has worked with clients from across industry to modernize their environments.
That brings us to planning.
In this phase a lot of decisions need to be made. If you have early platform adopters in your organization, this would be a good time to consult and learn from them. When planning we will be combining the knowledge learned from our training with organizational knowledge to build a solutions that make sense for the users.
There are many Kubernetes providers. Which one you choose may be influenced by any number of factors, such as where it will be running (in the cloud cloud or on-prem), what level of managed you want the platform to be, ease of installation, current vendors, the list goes on. If you are already running Docker Enterprise this decision may be as simple as continuing to use Docker Enterprise with Kubernetes workers, but for those on CE Swarm or otherwise looking for a new platform there are many options. At the time of writing, the Kubernetes site lists nearly 50 production environment providers, navigating this landscape is an important first step in your migration proper.
Once you have selected a Kubernetes provider, it's time to think about workflows, shared services and security models for Kubernetes and applications on the platform. At this point you may want to think about number of clusters, cluster size, and plugins for networking, devices and storage.
There are a lot of choices to make when planning your cluster build, all of which can have big impacts down the line. BoxBoat has a proven methodology that can find the best migration strategy for you.
Already have CI/CD? What about centralized logging? Monitoring? Alerting? If so, you may be able to lift and shift these over to Kubernetes without much problem. Some thing you may consider upgrading in the process. Interested in GitOps? Blue-green or canary deployments? There are tools for all of these but they each have their own benefits, drawbacks, and learning curves. We should also be thinking about how we minimize the impact of a failed deployment or how we might recover from a disaster.
Moving to a new platform gives the opportunity to evaluate, update, and standardize workflows. It's best to carefully consider these questions up front as they will be the foundation upon which you build.
Now that we've taken stock of our workflows and tools, it is time to consider what we want to bring forward into Kubernetes and what might need updating. The good news is, some of this can be informed by your Swarm deployment. Already using CI/CD? With a couple of tweaks you should be able to start deploying to Kubernetes. Already have a reverse proxy? This too may be able to be brought forward into Kubernetes. More tweaking for this may be needed to use native Kubernetes concepts and you may find that there are better fits available in the landscape.
For those of you who have not settled on standard technologies or are looking to update, things get a bit trickier. There are an overwhelming number of projects to consider when migrating to Kubernetes. For example, Ingress provides external access to your Kubernetes applications and there are 50+ variants. There are several options for each of metrics, logging, monitoring, container security. The good news is there is a lot of opportunity to introduce best of breed technologies to your organization.
BoxBoat has experts that can help you move to Kubernetes and DevSecOps
Kubernetes is only intended to manage service accounts, so normal users accounts must be Authenticated externally. Once authenticated, Kubernetes has a number of modes that can be used to authorize a request. Most often this is done via Role Based Access Control.
Security can be enhanced with custom admission controllers or open source projects like Open Policy Agent. Other areas to consider here are secrets management and network policies.
If you already have security policies for machines and applications, how will these translate to Kubernetes? The underlying hosts that make up the Kubernetes nodes will, of course, need to be hardened and patched, and the applications themselves should be hardened, audited, scanned, and segmented from one-another.
We've selected a provider, identified key projects we want to support, made initial determinations on issues of governance, now its time to build out some pilot clusters. Determine where these clusters should run, and what resources they need and get to work slicing up subnets, and provisioning nodes, storage, and backing services for these clusters. As with before, your Swarm deployments may inform where you want to run Kubernetes and what you will need.
If you don't want to manage your own cluster, our managed service, BoxOps, is a battle-tested, reliable way to get up to speed quickly.
It's time to select some pilot applications to move to Kubernetes. This will be a training ground and will provide valuable insights for a mass migration. Select some applications that are representative of your catalog overall. The most complicated application you have may be better tackled once your organization has more experience under it's belt. Likewise, the simplest single-service app you have may be a good one to start with, but will not help you down the line if everything else uses multiple services.
Pilot applications should be useful and meaningful but not the most business critical. These applications are useful to gain confidence and show value using a new platform. Becasue of this, and because mistakes will be made along the way its important that if the application goes belly up that the team has adequate time to diagnose and debug the issue. Your team will have to decide to accept this risk or create a backup plan for these pilot applications.
BoxBoat has helps companies re-platform to Kubernetes all the time we can help you avoid the commit pitfalls.
Environments don't always behave as expected. You don't get to choose when things crash but you can simulate failures and work on responding to incidents.
Take this time, before the platform is more utilized to see what happens if you lose a node, or lose quorum or any number of other scenarios. Learn how you applications may break and if this affects anything downstream. Put the environment under some load and try to find its limit.
In short, learn some lessons about Kubernetes with these pilot applications. Learn what works and what doesn't, and train the larger organization. Use this knowledge to do a full scale migration.
Now its time for the real work to begin. You've trained your core team, now you must teach the broader organization. Formal training and pairing up while on-boarding new projects will help this process along. If you're not already running Kubernetes in production at this point this is the time to start. New problems may emerge, but your early adopters should have the knowledge to work through these.
BoxBoat works seamlessly with your teams when its time for big changes, just ask our customers.
Stable Operations and Innovation
Once you've migrated and cut-over to Kubernetes, new projects that come online should be built with the platform in mind. The logging, monitoring and alerting tools should help identify and respond to issues. Now is the time to experiment and innovate. Solutions you wanted to prototype but were too busy when migrating should be tested. Ecosystem tools should be explored. Lessons learned and tools built should be contributed back to the community if possible.
Contact BoxBoat today to get off of Swarm and on to Kubernetes.
BoxBoat Technologies is an authorized CNCF Kubernetes Solutions Partner and Docker Premier Partner. BoxBoat offers services to accelerate enterprise adoption of modern DevOps tool chains, container technologies, and cloud solutions.