Many of today’s organizations jump into microservices without considering what success will require. Rather than assessing where they are, where they want to go and how best to get there, they’re hoping to make giant leaps directly from waterfall or Agile to microservices. If you’re one of the hopefuls who wants to teach elephants how to dance and fly, Red Hat can help.

“There are a lot of prerequisites you have to master first, but people are trying to bypass all that,” said Burr Sutter, director of developer experience at Red Hat. “They don’t realize they can deliver monolithic software in one-week sprints doing a lot of things besides microservices.”

There’s nothing wrong with microservices, of course. However, there are better and worse ways to adopt them.If you want to get things right the first time, Sutter and Red Hat recommend the following five-step approach that builds on critical best practices:

Stage 1: Re-org to DevOps. DevOps, like Agile, requires a cultural shift from hand-offs (throw it over the wall) to shared responsibility. That means collaborative problem-solving instead of finger-pointing and ticketfiling.

“You shouldn’t have dev versus ops versus security or anything else. You need a cohesive team,” said Sutter. “Once you have empathy for the people who have to stay up all night when things go wrong, the quality of code goes up.”

Stage 2: Enable self-service on demand. Developers shouldn’t have to wait days, weeks or months to get a virtual machine when software delivery cycles continue to shrink. With elastic infrastructure or infrastructure as code, provisioning can be almost instantaneous.

“How many days or weeks does it take for a developer to get a virtual machine and how many tickets have to be filed? I see companies making this mistake all the time.” said Sutter. “ Servers are cheap compared to the guy waiting for the server. It’s like telling the finance department they can’t use calculators and pencils.”

Stage 3: Automate. Do you have Snowflake servers or Phoenix servers? If you have the former, it’s time to switch to the latter.

“With a Phoenix server, your server template is code, not human. That’s super-critical,” said Sutter. I’ve talked to multiple customers about this topic and not everyone knows you have to write scripts. One company told me they had 300 servers and they weren’t sure if they could reboot any of them.”

Stage 4: Continuous integration and delivery. Continuous integration and delivery are often measured in terms of software delivery speed. However, there are some more subtle and important characteristics people tend to overlook.

“Jez Humble has some beautiful tests for this one,” said Sutter. “The one that blows peoples’ minds is, ‘The trunk is always deployable,’ meaning what you believe to be the source of truth in your code repository is ready to deploy at any given moment. That’s what your mindset should be.”

That’s a difficult test, though, so most people realize their trunk isn’t always deployable. For those who still think their trunk is always deployable, the next test is whether everyone on the team is checking in code daily. Then, if a build breaks, how long does it take to fix? Remediation should take less than 10 minutes versus a day or two. Finally, how long does it take to onboard a new engineer? Complicated architectures and onboarding practices tend to get in the way.

Stage Five: Use advanced deployment techniques. This is where blue-green and canary deployments come in. The subtleties are important because if continuous integration is done properly, the software team will want to enable continuous delivery by automating the deployment pipeline. With Kubernetes and blue-green deployments, all users receive an update or a rollback in a single click. With canary deployments, all updates are tested with a subset of users prior to a complete rollout.

“One reasons you should care about the subtle automations is because of all the CVEs that are discovered throughout the entire software stack,” said Sutter. In short, if you want to succeed with microservices, master everything else in order, first.

Learn more at www.redhat.com