Getting started on a microservice adoption isn’t trivial given the challenge of migrating existing data, merging with other data sets, keeping yourself in a ‘known good state’, and the new requirement of honoring contracts long after you’ve moved onto a new way of doing something. At least it’s just a technical problem that can easily be changed and monitored over the course of it’s implementation. I covered some options to start that half of the work in my prior microservice article and isn’t a goal here.

The real challenge comes in the other half of the work to lay the foundation for the microservices effort – the path to a DevOps supporting culture – which is our goal for this sub-section of the “working towards microservices” series. It’s the hardest half of the two parts given that it’s a business problem that can’t be easily changed or monitored – it requires changing the organization’s culture. Unlike computers which change their logic processing with a deployment, humans are pretty stubborn when confronted with new information, or conflicting ideas and thoughts.

You can’t directly change the culture just like you can’t directly change a person’s personality. You can change the culture indirectly by modifying behavior through the implementation of an intrinsic motivation and reward system, or working towards the implementation of a social-norm culture.Continue reading

In the work that I’ve done recently for evangelizing the principles behind our DevOps movement, it was interesting to hear the question of how microservices has anything to do with DevOps at all. It seems my blogging and marketing within the company is working as neither concept was widely known at the time I had started there and now people are getting to get the concepts well enough to know the difference.

They are very much correct in stating that microservices is an architectural concern and not something that DevOps dictates or even talks about. Even today, I am still marketing both DevOps and microservices in almost the same breath in most conversations. I have changed my messaging a to remove the confusion and put more emphasis on what each aims to resolve.Continue reading

I want to start off by saying that having a monolithic application isn’t always a bad thing, and this article may not necessarily be for you. Yet. It just comes down to the correct timing of using microservices when it make sense and then diving into that work at the moment it’s needed, and not a moment later. Utilizing a microservices architecture too soon will hold you back and slow the development process back, whereas waiting too long to perform the migration makes the refactoring effort very painful.

  • If you have a single product that was designed well, is easily maintainable, and carries minimal technical debt, you may not have a lot of reasons to invest into a microservices architecture. Or certain areas are becoming areas of concern for performance and scalability, then you may slowly split those areas out.
  • If you’re like the rest of us dealing with multiple products through acquisitions, mergers, or reorganizations that were originally built in a time long ago before best practices existed for online services, there is little hope that it is maintainable or carrying minimal technical debt.

Continue reading