Monolithic architectures are considered to be a no-no, but they're actually okay and serve a useful purpose, up to a point. For example, startups and small enterprises are better off having one consistent centralized approach than attempting to split things up a hundred different ways.
That's the view of Randy Shoup, a consulting CTO, former director of engineering for cloud computing at Google, and prior to that, chief engineer and distinguished architect for eBay. In a recent interview with InfoQ's Daniel Bryant, Shoup observes that monolithic architectures are simply the natural first stage of evolution in IT systems. Many organizations tend to naturally evolve to more diverse microservices architectures as time goes on and the organization grows.
"We say 'monolith' and we mean it as a slur, often," Shoup states. "But the reality is that most systems, or certainly for most stages of companies, that's a perfectly appropriate architectural approach. You don't need to distribute if you don't need to." For example, he illustrates, "most of the big websites -- Amazon, eBay, Google, Twitter, etc. -- started out as a monolith, and ultimately all, done through the process of convergent evolution, not coordinated in any way, have ended up with something we're starting to call polyglot microservices."
Startups and smaller operations, in particular, shouldn't necessarily lash themselves down with a particular architecture, he opines. Instead, be pragmatic. "It's important to know that you're going to evolve. No successful company that I've heard of today has the same architecture they started with. Don't spend all your time building for some far future that never comes -- build things that meet near-term customer needs."
What does it take to make the transition away from a monolithic system to something more service oriented? Shoup has a rule of thumb that small organizations that can sit around a single conference room table are fine with existing monolithic systems. Once the number of employees exceeds 100, however, it may be time to diversify. To get there, focus on a real customer problem first, Shoup says. It's more important to first change the organization before breaking up systems, he continues. "The first step you want to take is change the organization to the structure. You want to subdivide into teams and have them be responsible for the individual parts. That naturally lends itself to the technology being split up."
Shoup observes that it's inevitable that organizations will evolve into microservice architectures as customer demands grow more varied. "Microservices as a word is new, but the concept is old," he states. "It's SOA done properly."