If you stick your head out and claim you are using microservices or doing DevOps, you will in most cases get your head cut off by someone who disagrees. Why? Because in many eyes you are not doing DevOps if you are not using every concept of it, and you are not using microservices because there are some aspects of it that you have not incorporated into your solution.
Lately I have spent a lot of time thinking about this, because it confuses me a lot. To me the names and intentions of the technologies, methodologies and patterns are not the main concern. To me what is important is to find the best way to solve our challenges with new and existing software. I have started to use the phrases “moving in the direction of microservices” and “moving towards DevOps”, because I think we in most cases will never fulfil the “specification” put on these concepts, but nevertheless we will achieve our business goals.
Microservice concepts in monoliths
I had interesting discussions with a colleague some weeks back. He is working on a heavy monolithic application, and he was interested in looking into the concepts of webservices. He asked me something like: “If I get a fully automated test suite, covering all necessary use cases, and therefore is able to release often, maybe several times each day, is there any reason why I should do microservices”? This made me think a lot, because what he describes is a way of making your big monolith nimble enough to fit into a more agile world, without adding the complexity that comes with microservices, and without changing the runtime environment to fit a large number of loosely coupled services. Of course there isn’t one answer to his question. I could put on my microservices evangelist hat and say “well, you will still miss the flexibility of different SLAs”, “you will still be unable to release only parts of the system without the rest”, “you will still need to scale your system as one component” or one of the thousands of reasons for doing microservices. But maybe all this is not applicable for his application. Maybe all he need is to be able to release the big monolith more often. So perhaps what he needs to do is to get his fully automatic tests up and running, and maybe look at some of the concepts of backward compatibility in the APIs, that microservices rely on, and by that achieve his goals?
Closing in on DevOps
Likewise I had a discussion with a former colleague around DevOps. He was really into this “Full DevOps or no DevOps” line of thoughts and I couldn’t wrap my mind around this and start thinking that this is the only way to do things. Why not consider only those concepts that gives most value for you and your client, within the boundaries that you are surrounded by, and make the most out of the concepts? My current project has taken many steps in the direction of DevOps, but still we have a lot of concepts that is not met, or even touched. One of the most important things might be that we don't do deployments to production by ourselves. This has a lot to do with the boundaries set by the client. Still we have come a long way. We have more or less a fully automized continuous integration process, backed by containers, flexible test environments based on containers, issue tracking, source control and documentation fully integrated in the processes. Through this we have shortened the time to complete development tasks, we add a new test environments in a matter of seconds and we have very good monitoring on all levels. All these things gives us effect from the first second. Maybe taking the next steps is not the most efficient way of spending our time?
Hopefully I made you think, and maybe some of you will challenge me and my line of thoughts. Software development is difficult and filled with crossroads where tough choices must be made. I guess that's why we love it!