In part 1 of our microservices readiness series, we looked at how we determine if microservices is actually the right route for you. Once you’ve identified an actual need, ruled out alternative options as insufficient, and assessed your capabilities for handling such a project, you can move on to the next step: establishing organizational preparedness.
Let’s look at some key components that will ease your transition to microservices and enable long term success.
The Microservices Readiness Model
Company-wide considerations for adopting microservices
DevOps maturity
Can you deploy right now? If not, why? This usually brings up issues related to DevOps. If you’re not ready to deploy the application quickly to production, things will get more complicated when you have many services to handle. You may need to do some investigations on why this is happening. Even if you think you’re already “doing DevOps,” your maturity level may not be what it needs to be to handle a microservices project.
On one of my recent projects, for example, we had a team of folks who looked over the operations of all the applications for production. They were always stressed because they were asked to support code written by someone else. This type of siloed system flow isn’t a good fit in the distributed world—their DevOps story was very fragmented.
So ask yourself, is your organization willing to make the changes necessary to support a distributed system structure? If not, it can become a very frustrating experience to maintain and deploy microservices. It may compound problems that were isolated in one monolith. This is why conducting a DevOps Assessment is highly recommended. An assessment helps you gain critical insight on where you stand and develop a plan to optimize your pipeline and processes.
One of the major aspects of DevOps maturity is your level of automation. Higher automation is better for microservices because the number of deployments is expected to increase as microservices start to roll out.
Business and technology alignment
Lack of understanding around business needs is a widespread problem when it comes to microservices adoption. IT teams end up taking on too many changes at once without understanding what the impact to the business will be. I have seen teams migrating to the cloud, bringing in containers, moving to microservices, and adding events all at once. It rarely, if ever, works out. Figuring what makes the most sense for business—and prioritizing accordingly—should be more critical than jumping on new technologies and patterns.
Business adaptability
Another key question to ask: is the business ready to make changes to adapt to the new world of microservices? Microservices adoption brings on aspects of asynchronous communication. Do you have the business processes in place for this kind of change? Is business even willing to address these? If the business is less open to adapting, you can end up with synchronous and brittle microservices. We call that a “distributed monolith”—definitely something you wouldn’t want after committing top dollars to adopting microservices.
DevOps maturity, business and technology alignment, and business adaptability are company-wide considerations. You’ll need to deliberately push some of these practices throughout different groups within an organization.
However, there are also many tactical elements that IT teams need to consider before being able to implement a successful microservices transformation. Now, let’s look into those.
Tactical technology factors for a microservices ecosystem
Authentication and authorization
From the application standpoint, you should take a look at your authentication and authorization story. Is it ready to be applied to distributed systems? If the application is broken up, how much of the user information does it need to know? Can we keep the claims at a high level in the authentication service and let the business services apply it? Databases, and files, authentication and authorizations can become difficult to apply to distributed systems. It will help immensely to have this story straightened out before you go breaking apart your monolith into a microservices application.
Configuration files
That brings me to config files. I’ve seen extreme abuse of config files: These files had tons of business rules in them; they had items configured for a specific set of customers; every group would get their own set of over a hundred items. They also allowed an override which was stored in the database. So, in the actual physical file and overrides in the database, you would have to calculate an eventual right of the person logged in and give them access. These files were synced across many servers. If one team needed anything from this config, they would come to a grinding halt because it wasn’t easy to bring all this code into its own service—or just slap an API on top of it. Furthermore, these files also had different settings for feature flags. There are better options nowadays, like launch darkly for feature flags, than relying on feature flags. All this must be removed or migrated to something that’s more suitable for distributed systems. It is critical to figure out how to clean out anything that is in the physical files that your services are going to need.
Dependency resolution
In one of the monolithic applications I dealt with, dependency resolution was made in multiple ways and multiple containers were used. This tends to happen when the application is built over a decade or more. Tools like NDepend can help you identify dependencies to some extent. However, this application had some loaded dynamically, and they were not very clear. This sort of stuff becomes very difficult to handle when you’re getting ready to carve code out into its own service. Dependency analysis can go a long way—and it doesn’t have to wait. Performing an architecture assessment before you launch your initiative can pay off in time and resources spent later.
Small bursts vs. big bang
My goal here is not to create doubt about adopting microservices, but rather to help you clear pathways to getting there. None of these problems need to be resolved in a day—but they are also not going to go away if you don’t address them. Each of these considerations requires a deliberate solution and design. If not, they can bring your microservices application to a screeching halt down the line.
So do we stop everything and start addressing these things? You can manage progress and proactive problem-solving in parallel. The moment you create blockers to progress, that becomes another issue. Build upon the needs for each of the items described based on some small service—you don’t have to do a big bang style transformation. You can start with checking if you are ready for microservices, make some changes towards that goal, convert a couple of areas of your monolith to microservices and continue if it benefits.
Comments