The Middle Path Approach
The Middle Path Approach
Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
I’ve been doing software development for most of my career, so that I think myself as a software developer (or software architect), even though I’ve dabbled in solutions engineering more than once. This surely has an effect on how I see the architecture landscape, but I’ll try to be as objective as possible.
Historically, there have been two approaches in providing software solutions to business requirements:
- Either create custom software to address the requirements
- Or purchase an out-of-the-box solution to do the same
My software developer side was formerly more in favor of the first option. I thought that this way provided more flexibility than an editor package. During my professional life, I’ve come to realize that management sits on the opposite side, viewing out-of-the-box packages as less risky and less expensive. Even if I agree to the risk point, there are numerous cons to purchase such a solution:
- All projects I encoutered only planned for license costs. However, users generally ask for numerous adaptations that require a long configuration
- Some, if not most, of those adaptations require more than configuration, but hacking the product itself, which costs even more
- Changing the product has a great influence on the maintenance costs, especially toward upgrading: you’ll have to patch the code in the newer version, provided it is compatible
- Cutting on the adaptation side will also have an effect on the business side and will require a stronger change management planning
- Most products used are provided by (really) big companies: you’ll need to also purchase the associated infrastructure in order to benefit from full editor support (believe, I’ve tried going the other way to my chagrin)
Preaching that out-of-the-box solutions are thus cost-effective is the biggest lie of all!
So basically, it’s either take the risky development road or the costly/coupled product one. Shouldn’t there be an alternative path, that could address these issues?
Since the beginning of the year, I’m working for a company that I think provide such an alternative. It comes in the form of a product whose features include:
- a basic platform developed with Java & Spring and providing a plugin architecture
- an extensible business model
- a service layer, designed around an interface and an out-of-the-box implementation. Implementations can be replaced through a developed plugin
- a templated web layer, based on Spring MVC that can be modified as needed
IMHO, this is the best alternative I’ve ever seen. This way, you can get the whole shebang in production very quickly, adapt the system to your specific needs (either before production or by incremental steps) and still be able to upgrade easily with each version. Software companies should probably invest in migrating their products to this kind of architecture.
The company is hybris, and I’m very happy to have joined their ranks since the start of this year.
Published at DZone with permission of Nicolas Frankel , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.