I just listened to a Software Engineering Radio Podcast featuring James Lewis on Microservices, and I have to say I am in agreement with almost everything that he said. I love the term Microservices, especially as a way of describing an implementation SOA (Service Oriented Architecture) rather than a way of replacing it. I am not sure I can use the term to describe my own work, because I am not sure I have enough in agreement with the community that is building agreement on what it is. But one thing I think for sure, it definitely does not mean a SOA implementation using a Service Bus. An other thing that stuck out to me was his definition including the concept that a microservice should have only one reason to change. Object oriented principles used at the service layer. Of course this poses the same question that we had at the object layer. What is one thing? If I have a taxi and I am moving a customer from one location to another, is driving the car one thing? or is changing gears one thing. For now at least I am going to go with the idea that its driving the car. I might go with the phrase that “they do one useful thing”. An Address service, that stores and address for my user might be useful, but a User Profile service might be even more useful. The devil as always is in the details. And you cant answer which is beter without understanding the Business domain. Something else that is not optional when designing Microservices.
I saw yet another tweet linking to a criticism that we should be careful what we call a REST API, and linking to a blog post of none other than Roy Fielding explaining what constitutes a REST API. I am not arguing that we shouldn’t be precise, in our language, but the reason so many people get confused is because the REST API is a Unicorn. This mythical beast has never been seen. Seriously has anyone, anywhere, ever blogged about a real Rest API that was worth a dam? If you follow the concepts of REST API to its logical conclusion you find that the perfect client application has already been invented. Its called the browser, and the application is the web. Anything short of this literally comes up short and is severely criticized. I am yet to see anyone that has come up with a Hypertext driven API that provided real value, as in more value than the cost of creating it. Please someone show me the true value, until then I am going to create HTTP API’s, I will think about resources and I will try to use Hypertext, but I sure as hell won’t call it REST.
At my company we have been on a mission to outsource our IT department, including the outsourcing of custom applications. We are not a software company goes the mantra. That’s not what we do. So we buy a product from a vendor, in most cases this is the obvious thing to do. We are not going to write our own Email system or word processing application, but what about those custom applications that is specific to our own industry, and directly support our employees in their daily work. Should we find a vendor that offers broadly the functionality that we need. This seems to be a popular thought. We will buy the products, do a small amount of customization and we will be responsible for the “Glue” to make all of these disparate systems work. The net result should be smaller more cost effective IT departments.
Ok that’s a possibility and I don’t want to get into the risks this plan has I will save that rant for another post, but instead I want to look at the impact of the Cloud, and in particular Platform as a Service (PaaS). This substantially lowers the overall cost of custom applications. I can recall projects where a third of our time is taken up moving from QA to production, troubleshooting the same bugs over and over again because of environmental differences and the need to do most things manually with production engineers in place of developers. But not only does PaaS save us some time and resources it rebalances who we need on the team. A much higher proportion of our spend should be on meeting the functional business requirements – developers writing code, with a lower spend on engineers and hardware. The cost of quality requirements like scale and performance can also be reduced with solid cloud architectures, rather than big databases, and big hardware. This much larger percentage of our resources allocated to the meeting of functional business requirements means that the knowledge of our business process is much more valuable. Who better to know those processes than your own employees the developers who have been building and maintaining you systems. And who would you rather have this intimate knowledge of your business? Will the cloud save a few of our jobs?