This series of blog posts is based on a talk I did at Dotscale Paris, 2015
How many of you have written software for a company that wasn't part of the main product? I imagine it is many if not all of the people reading this blog.
In the business world, this is called overhead -- work that is done to move the business forward but is not part of the core product. Generally speaking, businesses try to remove overhead, because while it may be important for the business, it's usually work that other businesses are doing too, and therefore can be outsourced.
This is in fact the general philosophy behind AWS. To let them do the heavy undifferentiated lifting while you focus on your core product.
Chances are the platform your product runs on is one of these undifferentiated pieces of overhead, even if you wrote it yourself and it's "totally custom" to what you do.
Build or Buy?
So if your platform is mostly the same as everyone else, should you build it or buy it? I would say that those are two sides of the same coin.
You could go the route of building yourself a platform, spending the time and engineering resources to write all the code, and then iterate on it as you find all the edge cases. Or you could spend time evaluating solutions and then integrating with them. Those solutions will probably solve 90% of the problems you have, leaving you to engineer the remaining 10%, as well as figuring out how to integrate what you buy into your own workflows. One big benefit of using existing software is that people smarter than you and I have already done the work to find all the edge cases.
Then there's open source, which is really just another form of buy, except that the cost of the software is "free". Free for the code, but the integration time is just as bad as a paid product if not worse, because as is typical with open source, more time has been spent on building the software than documenting it.
Lastly there is the PaaS option -- you could pay someone to run all the infrastructure for you, but then you have to pur your data and your code into their system and do things their way, once again incurring additional engineering cost to make your workflows follow their methods, and the extra risk of your data on their servers, unless they manage resources in your account (like CloudNative).
Monolith or Microservices?
This has been a very hot topic for the last few weeks, and there has been a lot of debate. I will throw my opinion in and say that I believe microservices is the only way to properly run a distributed cloud infrastructure. That being said, I usually advise companies that are just starting out to build a monolith. Why? Because there is a lot of overhead in running a viable microservices platform and it isn't worth spending time on when you're just getting started.
Success tends to follow a pretty standard pattern:
First the company starts by building their code as a single monolith, because that is the easiest to build and deploy, but is also the least reliable and scalable. Eventually they reach a point where they need to scale, so their break out the most used parts of their application in to separate services, which lets then scale independently of the rest of the application.
Eventually they build out a platform for running their microservices. The problem with this platform is that it is only "good enough". Since the platform they are building isn't core to their product, they stop when it works well enough to achieve its purpose. This is fine for them, but it means that it is missing polish like documentation and good UX/UI, meaning it is hard for new users to on-board.
This is an argument against building your own microservices platform. The other argument is the cost. When talking to various companies that have gone down this path, they all say the same thing -- they they are spending about 25% of their engineering resources on building their platform. Either they have a team dedicated to the platform that represents 25% of their staff, or all of their staff spends about a quarter of their time on the platform. Either way, that is a huge cost.
On our next episode...
Stay tuned to this blog for the next post in the series, where I'll describe the ideal microservices architecture (or you can watch the video).