Legacy architecture — also known as the backend you are stuck with. As software developers working in software outsourcing — or really nearshoring — we are used to this concept. At Code4Nord, we work to be flexible, adapting to each project, servicing the full software development lifecycle. That being said, it’s quite exciting to witness the deliberate move most forward-thinking organisations are making from away from a legacy of monolithic architecture toward a microservices architecture.
Today we will discuss the benefits of microservices and how they are driving an upturn in software outsourcing and nearshoring.
Where did microservices come from anyway?
First, let’s explain what a monolith is. Take a moment to imagine the old way of working in IT. The back-end architecture was as large and as complicated as the organisation itself. That meant updates were carefully timed, even factoring in downtime. And they only happened every few months or even once a year. Following a Waterfall project management model, every piece or this complicated path was roadmapped out by the CIO far in advance. Despite of any new tech or competitors’ movement, there was rarely a deviation.
Conway’s Law says that the code will reflect the organisation behind it. Some say it may work in reverse where the code will determine the org chart. Either way, legacy architecture was part and parcel with the slow-moving, slow-to-release orgs of yesteryear.
How did we escape this legacy?
First at the turn of the century came agile project management, which emphasised “responding to change over following a plan.” Then that software cultural change continued with Scrum, which encouraged us to break into smaller teams of eight or fewer and to focus on short-term, often two-week goals and achieving smaller accomplishments. Then Martin Fowler started talking about the tech side that reflected that cultural change — and he mainstreamed the term microservices architecture.
In contrast to the snail-like pace of Waterfall feeding into legacy, microservices are smallpieces of code that are designed to perform a certain function or service. Each of these services is built around a specific business capability and is deployed independently, via automated releases and usually after automated testing.
Fowler requires a microservice to:
- be independently deployable
- have a single responsibility
- be loosely coupled (services don’t need to know a lot about each other to connect)
Also Read: Our colleague Adi on Microservices and Azure Service Fabric
The rise of miniservices
Lately, there’s also been an increase in the term miniservices as well. Event-driven architecture — or designing for something a customer or consumer does — has seen a small step back from microservices which breaks up everything into tiny, independent bits. Instead with miniservices you can break up those apps into the smallest functioning independent components that still allows you to communicate. This could be as simple as something in a shopping cart going from the state of “pending” to “sold.”
This all follows another trend toward understanding the customer and consumer experience more practically and visually, leveraging behaviour-driven development and user stories to map out customer experience. And then plan the product roadmap to those use cases. (Maybe we need a new law that architecture and teams model themselves after UX? I welcome the name Riggo’s Law.)
Whichever you use — for most teams it may be both — the benefits of microservices and miniservices are relatively the same. There’s very little centralised management of these services, which allows developers a welcome freedom in terms of programming language choice and where the data is stored. It takes us away from spaghetti code and toward independently deployable, testable, and maintainable chunks. And this all supports the movement toward DevOps and agile software development, as each small team can own and focus on one service.
Basically it makes for more stable systems that adapt to and deliver to the market faster. And it makes for more intrinsically motivated engineers.
It’s also great for software outsourcing.
How could microservices be helping software outsourcing?
Let’s refer back to Conway’s Law. Whether the teams are expanding and contracting based on service needs or if the code reflects the people, it’s certainly all about flexibility. It allows you to build teams in response to the task at hand. And it makes it easier to leverage software outsourcing to bring in outside experts on a project-by-project basis.
Yes, microservices allows your developers a certain level of freedom to build with the language and even tooling they prefer. This lends itself to specialisation and devs being great at building and maintaining smaller pieces of code. On the other hand, this specialisation means things will come up that they won’t be able to service. That’s where it’s easy to bring in software outsourcing to fill that niche needed. Whether it’s for a shorter or a longer-term project, software outsourcing avoids the risk of hiring someone for an edge case.
Microservices make for better long-term code, but that doesn’t make it easy. Each engineer can be the master of her own code domain, but may not know how to manage and secure the overview. At Code4Nord, we see an increase in requests for help with microservices orchestration just for this reason. We help you map out your service-oriented architecture (SOA) and we make sure your team still has control.
Another benefit of microservices is that it allows for clearer role-based access control (RBAC.) Nearshoring is different from software offshoring not just in location, but in the fact that, at least at Code4Nord, our team actively joins your team, from daily stand-ups to testing and releasing… if you want us to. We acknowledge that you may be reticent to give outside developers access to your code.
One benefit of microservices architecture we haven’t talk about yet is security. Since microservices code is isolated, it allows for you to only give our team access to the pieces you need us to work on. Don’t worry, it won’t hurt our feelings, we are confident we can show are worth and that the proof is in the proverbial pudding.
Ready to get started with microservices?
If you are building a greenfield tech project, then for sure microservices is the way to go. You’ll find you can pivot much quicker in response to customer demand.
Already have a large monolithic architecture? Then you can’t just run off to microservices. You’ve got to go step by step.
Building anything new? Start with building that bit separately and connecting the larger collective part of that miniservice to the whole.
From there you need to look at your code holistically and find logical points to build in parallel before breaking them off. Focus on those events and stages in the customer experience. It’ll start you looking at your code in not only a more service-oriented way but a more customer service oriented way.
Unsure where to begin? Partner with Code4Nord. We have the agile mindset and technical knowhow to help you on this epic code journey. Go on, just click on that Contact Us button at the top of your screen. You know you want to help great people make great software.
Share your microservices (or miniservices) journey in the comments below!