The first reaction non-development IT people have when seeing their company’s microservice is very similar to a parent looking at their child’s art. “Oh! It’s a…what is this? A microservice? Wow… well, isn’t that something! I like how the blue, green, and red make a nice brown color. Let’s put this on the refrigerator.” Of course, that art could be the beginnings of the next Frida Kahlo if only the parents understood. Likewise, we need to make certain that others in the company understand how microservice architecture can benefit the entire company.
Sadly, one large area of friction around microservice adoption is that deployment is often neglected until the last moment. This causes delays, organizational thrashing, and a feeling that microservices are not worth it.
Here's the good news. With specific steps, development and DevOps teams can prepare for releases and enable the ideal “you build it; you run it” process for microservices. We’ll structure this preparation using the metaphor “Ready, Aim, Fire,” which is the microservice approach to “a stitch in time saves nine.”
[ See our related article: How to make the case for microservices ]
Ready:
First, identify the dependencies of the microservice, and include the technology stack. Deploying a container in Kubernetes will be far more complicated (especially if you don’t have Kubernetes infrastructure in production) than a simple WAR file that runs on Tomcat and speaks via a RESTful API. You also might be refactoring a monolithic application and pulling out functionality that will be in a separate microservice used by the now slightly less monolithic application. Of course, that creates a dependency for the older application.
Second, prepare a list of all the steps needed for deployment. My developer friends, “just throw WAR file on my laptop” or “cf push” is not a list of steps. Creating this list of steps will require discussions with DevOps teams, site reliability engineers (SREs), database administrators (DBAs), and security teams to identify all the corporate and technical hoops to jump through. Yes, this will be difficult and a bit out of a developer’s wheelhouse; it will require engagement with others in the company to create an exhaustive list of steps. It is very much worth the effort in breaking down silo walls.
Third, identify which steps are already automated, those that can be automated, and those that won’t be automated. You can’t adopt “you build it; you run it” without having push-button deployment to all environments, including production. It might be necessary to have someone else push the “release to production” button. But, you need to make certain that will be automated and completely hands-off for those people. If not, you shouldn’t even bother with a microservice… unless you are engaging in resume-driven development.
Aim:
Now that you have a list of release dependencies, a list of release steps, and have identified areas to automate, now it’s time to plan the work. Begin with the biggest rocks and work down. If the longest step takes two weeks to perform based on ticket history, start thinking of how to get that two weeks down to seconds. Do we need to automate approval or the actual work? Who is the leader that needs to agree on the change to seconds and how can they support you? This step is more about project management work than anything else. Find the blockers and devise a plan to remove them. Lather, rinse, repeat.
Make sure to include “build vs. buy” discussions in this step. Will you be handcrafting your own DevOps tooling for your microservice or will you leverage your monolith existing tools? Should you upgrade your DevOps tools for the monolith with an eye for the future microservices? With steps Ready and Aim completed, you will have a clear list of requirements that you can use for building or buying your necessary tools.
Fire!
Finally, we can begin to execute. The first version of your automation should be used in development. As it matures and becomes battle-tested, you can then release it to the next stage, maybe dev integration testing or first level testing. Continue to improve and release it along with the code, or at least in parallel. Just like your application, you’ll need to test and improve your new deployment mechanism. Communicate early and often to help stakeholders not only get comfortable with the change but to allow for evangelism along the way. You will find it helpful to remind stakeholders why this change is a good thing and how the company will benefit.
Don't forget to celebrate and improve
Remember to use the first production push of your new microservice as a reason to celebrate. That is a very big step and represents a lot of hard work. Also, remember to reflect on what the team has learned from failures to continue to improve.
Microservices and DevOps are two things that should go hand in hand, but to move to a “you build it; you run it” process, you will need buy-in and insight from everyone who touches releases today. By performing some preliminary work with your microservice releases, you can avoid unknown unknowns and deliver not only great software, but also a great way to manage and execute the deployment process.
[ Read next: Microservices and containers: 6 management tips for the long haul ]
