In the software world, there are often new technologies coming to market, new fields to explore, new techniques to use, etc. Filtering through these in itself can be a challenge. Deciding when to move forward with one in practical applications can be even harder. Many times as developers, we will be brought a problem that we can solve in a way we’ve heard about or read. This is when theoretical example attempts to meet practical implementation. We ask ourselves “Does [X] tool I read about recently solve this problem?” or “Would [Y] really work in my organization?”. This is where we can employ the proof of concept.
Authored by: Trevor Richardson & Todd Brunia
In a previous article we discussed some of the positive characteristics of microservices that we’ve found while implementing them in a production setting. Two of the primary benefits we discussed are the architectural agility and enforcement of api boundaries. While you may find those and many more benefits from using microservices, you will also find that the positives don’t come for free. In this article, we’ll discuss some of the challenges that we’ve dealt with in implementing a microservice-based architecture. Being aware of these will save you the time and frustration that we experienced early on in our experience with micro services!
A recent topic grabbing the stage in the software community is the use of Microservice Architectures. Microservice architectures are often sold as a great way to enhance a project’s agility over a standard, monolithic architecture. While this can certainly be the case, and there are indeed many benefits from using microservices, the use of a microservice architecture also brings about many unwritten challenges to the way software is designed, developed, and put into production. In this article, we will lay out some of the positive characteristics specific to using microservices that we’ve found while implementing them in a production setting.