There’s plenty of software-speak that goes whooshing over the heads of most people - and even some of the heads of those programming! Two of the terms that you might hear thrown about in the world of software are microservices and web services. These are both ways of defining software products: by breaking larger software products down into manageable chunks that can talk to each other. Let’s take a closer look.
The microservice architecture involves breaking down a software application into its smaller components, rather than just having one large software application. Typically, this involves splitting up a software application into smaller, distinct business capabilities. These can then talk to each other via an interface.
Let’s take a basic example, for instance your business is a small retailer. Instead of going and looking at your shelves all the time to see when you need to reorder stock, you want to automate it, see what’s been sold and order when stocks are low. You want to be able to effectively manage and update your product catalogue rather than just knowing off the top of your head. A software product can do all these things at once - however, breaking it into these three main capabilities (catalogue management, inventory management, and order management) means separation of both logic and services, and makes more sense.
You can do this just in a regular monolithic software - do separation of components - however a microservice architecture takes it further. Each service component is a piece of software within itself. The inputs and outputs that can flow from the other services are only defined by an API (Application Programming Interface), which ensures security and atomicity of each component - while still being able to talk to its neighbour software components, making it far easier for testing and reuse if necessary.
So, if microservices are like mini applications that can talk to each other, then what are web services? Well, they are also mini applications that can talk to each other - over a network, in a defined format. They allow one piece of software to get input from another piece of software, or provide output, over a network. This is via a defined interface and language, such as XML.
If you’re running on a network where your software components or services won’t be co-located, or you want the option of running them in separate locations in the future (e.g. cloud to cloud, server to premises, client to server, server to server...) then you will likely need to use web services in some form.
What’s best for my project?
For anything beyond a singular-function software, it’s advisable to choose a microservices architecture: developers can work on distinct parts, it’s easier to test, and it generally takes less time to “put together”. Single teams can work on single distinct business components.
If your software needs to speak to other software over a network, or you’d like the software itself to “live” in separate places, then you’ll likely need to use web services to do so.
So, yes, your software can use both microservices and web services at the same time - in fact, it probably will.
The right architecture for your project of course depends on the requirements themselves. For a small program that exists solely on your phone or laptop and doesn’t require a network connection for any reason, then you might not use a microservices architecture, nor any web services to get the job done. In this case, the software development is probably pretty straightforward and won’t take too much time to develop (unless the operations are complex or compute-heavy, there’s in depth graphics, etc.).
As the saying goes, there’s many different ways to skin a cat, and so too is the case with software development - there’s no “right” way to do something. You could develop a huge, complex, network-heavy program without using microservices or web services - but it might be a big mess that takes forever to develop (and never makes it out of the testing phase).
Choosing the right design architecture for your software in the beginning is critical to seeing it be developed along a healthy time frame, ensuring it’s well-tested, and that it’s robust enough to ensure a change doesn’t break the whole thing.
If you’re unsure about what type of architecture(s) is best for your project, then why not get the experts to take an eye over your requirements? At CodeFirst we pride ourselves on designing software with the right architectural pattern in the beginning - so you don’t run into problems further on down the track.