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.
For someone who can barely keep his blog up to date, I would still love to write a book one day. I’ve been told I have a great amount of technical talent multiple times, can sometimes firehose people asking for an intro to a topic, or get a bit detailed. So I’ve got plenty in my head to share, I’m just not sure on how to distill the knowledge I have and what topics people would be genuinely interested in reading. My frontrunners for the topics I’d love to write about are:Continue reading
The current project I’m on is finding a path to adopting DevOps in an enterprise environment. The weeks of preparation, pitch to directors, and executive management is in the past, I’ve received the necessary approval to proceed without any limitations (outside of additional authority to actually enforce change). Still need to persuade each product group to see the light and change on their own, while guiding them down a yellow brick road.
News had spread a little that we got the green light, and some individual contributors in the company were interested in what DevOps was really all about. There is as much curiosity in learning more about it as there was fear of job loss from the change, even though no headcount modifications were even in the pitch. The only changes we suggested were lateral moves in the existing reporting structure.Continue reading