Microservice Architecture vs Monolith
Microservices is an approach for building flexible, independently deployable software systems. Their prominence raised with the boom of DevOps and continuously deployed systems.
In my opinion, the Microservice Architecture is definitely the best approach for building some kinds of applications. But it certainly brings non-trivial overhead, both performance-wise and process-wise. However, for other types of applications, a well-designed monolith might be a better way to go. We will deal with this more in depth in a separate post.
To branch, or not to branch
There are not many technologies that took the world of enterprise software development over just as fast as Git did. Git branches are for free and working with them is rather easy. We adopted various workflows like the Git flow or GitHub flow to create a process for coping with branches. Nevertheless, there is one problem.
The code in the (feature) branch is a code which is written but not in the production yet. It’s an asset that we invest the time into to create it, but it does not provide value yet. Over time, the value of the code in branch decreases and the code transforms little by little from an asset to an obligation.
An alternative to it is the called Trunk Based Development. The Trunk Based Development is a practice where all developers collaborate on the code in a single branch called ‘trunk’. In this scenario, the features developed but not ready for production are not in a separate branch but hidden behind Feature Toggle.
The Trunk Based Development approach moves the complexity from version control back to the source code. Based on your particular scenario this may be a good thing.
To refactor or to rewrite
According to our experience, any bigger enterprises have a few in-house built applications written by mythical legacy real developers. These developers are now retiring and their applications do not need changes so often. However, change is an inevitable part of the business. The only business which is not changing is a dead business. Hence applications need to adapt as well.
When it comes to applications, developers are rarely the only stakeholders deciding, if to rewrite or to refactor. Nevertheless, on a smaller scale, it’s part of the daily developer’s life. Ask yourself a question: Is it feasible to extend this module, class or method, or is it better to write it again from scratch?
Writing from scratch is definitely more attractive for developers. But even on the smallest version scale, it’s usually more work and the result is often unpredictable.
So rewrite or refactor, that’s the undying question of software developers. Nevertheless these days, with a boom of new technologies, from DB to Web, to AI, we believe this question is valid more than ever.
Native Mobile App vs Hybrid Mobile App vs PWA
From early inception of mobile applications developers needed to ask themselves: Is it a real application or is it just a glorified wrapper around a website? Over time the situation got even more complicated.
Nowadays we can pick between Objective-C and Swift on the native iOS side. Honestly, this is an easy pick. Things get more complicated when it comes to Android where you have to choose between Java and Kotlin.
When it comes to hybrid mobile applications, things start to be even more difficult to decide. We have Xamarin, Ionic, React Native and more than 10 other options.
If you decide to build your application as a website, progressive web applications (PWA) are an option for you. PWA is not really something new. It employs technologies – some of which are around more than 10 years old. Even in some sense, PWA is a buzzword, this trend can’t be ignored as thanks to the trend, web technologies are viewed with a very positive sentiment.
Slices vs Layers
In regard to the enterprise software, we have been building multi-layered software for decades. We usually start with the database layer on the bottom, we add a data access layer on top of it, then we add a business layer and on the top, we have the UI layer. This is a quite proven approach, however, it has some limitations. In a layered architecture, each layer depends on the layer above and the layer on below. This is ok, but only to some extent. As the application grows, the layers grow with it. Over time each layer becomes a monolith with a dependency on the monolith and on the layer above and below.
An alternative approach would be to design an application by feature slices. Each feature as a self-contained micro application (one might say microservice ?). Using this approach will reduce coupling between individual slices. The risk here is a reduced uniformity and a possibly lower code reuse and therefore lower maintainability.
We prepare a series on all of these topics to be handled more in-depth so watch out for further news posts here.
