Nothing is impossible and shall act based on facts, not believes.
There is no one size fits all when it comes to software, the right tool shall be used when the right time and environment for it has come and shouldn’t result from a poorly informed hype caused by a few blog articles from one of the Tech Giants. The reality we see on the market and within a lot of individual software developer teams is quite the opposite.
While we do understand the appeal of the new and unknown, this can result in serious problems for the company for which those applications are being developed for. Especially if the architecture is not actually studied and just being picked up from one of the aforementioned blog articles. While many of the big tech giants indeed have many of the best software engineers out there, not all of them are as competent as they present themself. This is important to understand to make a decision that is driven by facts.
Don't run after the hype
One example of this is the today almost infamous microservice architecture, which is a great way to solve a lot of problems, both in scaling the software itself, but also the teams developing it. They have a lot of great attributes if they’re done right.
Microservices are by nature, independent, usually distributed, scalable and elastic.
Microservices have a few rules, one of the most important is called decoupling. This means a service does not actively know much about anything but itself. This includes also the fact that a microservice in its pure logic has no idea how to talk to other microservices. Which doesn’t mean it can’t, but the communication is usually strictly abstracted away.
Lazyness during the design will make the operations a nightmare
Unfortunately the most common way to implement the communication between services is being done by using a technology called “message queue”. The message queue is nothing but a broker that takes a message and delivers it somewhere else, it is essentially a derivative of a worker queue, but with fewer features. The problem with this approach is that using a message queue degrades the microservices from a distributed system to a decentralized system, or often even worse a centralized system, and further introduces a single point of failure of the worst kind anyone can ever imagine.
In a proper designed microservice architecture any component can fail and the rest of the system would not be affected, this is referred to as elasticity. But now imagine what happens when the message queue fails for whatever reason: The effect is terrifying and means that absolutely everything is offline, this in turn means that the message queue is not just a single point of failure, it also is an absolutely mission critical component from the very moment it gets introduced into the system. This means it needs a 24/7 operational team always on hold to jump in and constantly very carefully monitor this system. And this is just the start, also scaling becomes way more difficult and expensive as soon as you start to saturate the capacity of your deployed message queue. This contradicts an otherwise very flexible and scalable architecture with virtually no operational headaches.
This is where you can count on our WizardTales level knowhow, we know when which solution is appropriate. In this case for example a gossip protocol, for example SWIM, is usually a good solution to solve the discovery instead. Paired with chained circuit breaking is all it needs to stabilize the communication.
Simple is often better
Microservices are not always the right solution, especially if the application is small and doesn’t need to scale into big demands, a traditional monolith removes a lot of overhead and often is more than enough. A monolith that is designed right with a few principles followed, what we call a quasi monolith, can be however easily transitioned into a different architecture later on. This gives the freedom of a very easy to operate software while maintaining a certain degree of flexibility to grow it out.
Simply stating: We love software!
We run a lot of inhouse and customer development projects. Nothing is too big or too scary, we love to work on solutions in virtually all domains. Be it IOT, Artificial Intelligence, embedded, security or beautifully designed web applications. Our work includes the inner workings of our Data Center Offerings, the several companies and StartUps we are involved with, but also projects that resolve from our work with our customers. We are a strong partner with a holistic view on the whole of the projects we are working on. With strong knowledge and skill in our four key expertises we excel: Software, Artificial Intelligence, Hardware and Knowledge.