I find this article lacking, since it paints a too simplified brush over monoliths. Some missing points:<p>"Monolith", at least if you define it as a single process rather than a network of (micro)services, can still be modular in nature. Using a flexible core, you can build your application as a combination of modules, rather than as a single large codebase.<p>They also don't have to be a SPOF: in our architecture, we deploy monolith<i>s</i>, one for each client (ie, company, not user), while keeping them isolated from each other. This allows us to scale pretty much indefinitely using a simple architecture. We don't have a huge sharded database, but small bundles of databases. We don't have datacenter-wide load balancers, rather we allocate clients to certain groups of nodes and use DNS to point them there.<p>This works because our clients don't really need to interact with each other, unlike say, social network users. Do yours? If not, why are you building a huge and complex mesh of services?
Author without even knowing it described common microservice architecture problems that are faced in front-end. (Because in microservices front-end is consuming API and is usually a SPA)<p>- The single point of fragility<p>Yeah, if you have an js error in your syntax the whole front-end application will not work.<p>- Slow CI<p>Actually the front-end nowadays is the bottleneck of any CI if it is using React/Angular2 because of all the tree-shaking and optimizations. It can take a good 8 minutes to build, optimize, tree-shake, AOT etc. a modern SPA application.<p>- Slow development cycles<p>This has nothing to do with monoliths whatsoever. If your codebase is crap it doesn't matter if it's microservices or monolith.<p>Anyway, I digress since this is a textbook Mary blog article.
I would like to argue that a microservice architecture is frequently a response to the scalability limits of traditional databases. Decomposing a monolith into multiple services (with each service interacting with only its own database) is essentially a form of vertical partitioning. It's a way to delay sharding.<p>Microservices are nice, but they seem like a heavyweight way to "force" module boundaries to exist. Potentially, if database technologies improve, there might not be a need to split up a monolith until much later on.
> early adopters have been tech behemoths such as Amazon<p>Not true. Amazon is heavily service-oriented, but quite wary of <i>micro</i> services. You need the right size - microservices are often too slow and require a lot of work to debug.
> Emergency-driven context switching: we may have begun working on a new feature, but an outage has just exposed a vulnerability in our system. So, healing it becomes a top priority, and the team needs to react and switch to solving that issue. By the time they return to the initial project, internal or external circumstances can change and reduce its impact, perhaps even make it obsolete. A badly designed distributed system can make this even worse — hence one of the requirements for making one is having solid design skills. However, if all code is part of a single runtime hitting one database, our options for avoiding contention and downtime are very limited.<p>Flying Spaghetti Monster, this has been my life for the last three months. React, react, react. Spend two days working on new features, spend the next three on emergency bugfixes for old releases, rinse and repeat.<p>I'm so ready for a vacation.
I'm not sure what we (bioxydyn) have done constitutes a microservice but we have split different parts of our business logic into separate executables that communicate using HTTP and a central data store. Our product is a data processing pipeline and we took this approach for several reasons which I may have missed in my skim read of the article. Firstly different parts of the pipeline have different resource requirements and would thus be hosted on different hardware configurations. Also parts of our pipeline lend themselves to different designs and languages (some Java, some C++) decisions which are also influenced by the availability of third-party libraries. Finally, by designing the overall system as a set of coordinated individual services we allow greater flexibility in our deployment model; allowing us to cope with some unknowns around scaling and regulations in different environments.
I wonder how much criticism and hatred this post would've received had it not used Rails as the example case. Monoliths exist in other stacks (obviously), but the Rails community always seem to take offense first. This is the first time I've seen such an opposition to micro services (maybe I'm not looking through forums hard enough).
Everyone is hating on this post -- for good reason -- but keep in mind that this is an inbound marketing post for a CI company. It's in their best interest to have you split your app into many standalone pieces which will each require an individual testing setup.
Another aspect to consider is, time taken to run regression and automation tests on the Monolith, by both devs & QAs. This affects frequent release of software considerably l.
I'm working on a large system with is based on microservice architecture. We primarily use microservices to decompose the system into modules and enforce module boundaries. Things like scaling or performance is not so much of the problem, the monolyth would most probably work just as well.<p>Technically we write Spring Boot-based microservices which mainly exchange messages over RabbitMQ and in some rare cases call REST interfaces of each other.<p>Below a few problems I have with this architecture:<p>* Code duplication. For instance, we have to implement more-or-less the same DTO on both sending microservice as well as receiving microservice.<p>* Refactoring across microservices takes a lot of effort. In several cases we didn't cut in the right places and had to move functions across microservices. That was always quite difficult, and we also had to implement migration routinges (for databases as well as unprocessed messages which may be still in queues).<p>* Versioning and synchronization of messages. Our system receives events from the number of external data sources which trigger processing in the microservices and finally produce results. Since message exchange is asynchronous, older messages may overtake newer messages so we have to version them in order to not output obsolete results. Another problem is that messages travel different paths in the system, so it may happen that a microservice receives two messages which are based on partially obsolete data. Consider two sources A and B which produced events a0, a1, b0, b1. Later in the system a microservice receives two messages p and q based on p(a0, b1) and q(a1, b0) respectively. These messages are not compatible and cannot be processed together. But in order to detect this we have to track version of incoming events (a0, a1, b0, b1) all along the processing.<p>* A hell to debug. At the moment we have a network of around 40 microservices which process data from ca. 6 sources and feed 3-4 receiving systems. Microservices are quite complicated, the work with often incomplete or incorrect data, employ a lot of heuristics and make a number of assumption which are sometimes proven wrong. If any of the receiving systems report a problem we have pretty hard time identifying which of the few dozen microservices failed. Reasoning about asynchronous message processing is very difficult and approaches like remote debugging actually change the behaviour of the system.<p>* Tools. We employ maybe a dozen of different tools and custom scripts solely for the purpose of configuring, deploying and running our microservices. We'd most probably only needed a small part of them for a monolytic system.<p>From the other hand our system is a fourth attempt to solve a very difficult and important problem for our company, the problem which persisted for more than 30 years. And it is the first attempt which is so far successful.