The term microservices is used fairly frequently when people talk about developing modern software solutions, but what does that actually mean for payment and financial applications? Let’s take a broad look at what a microservices architecture is, how to develop applications using this architectural style, and the benefits of developing applications this way.
What are microservices?
When we talk about microservices in application development, we are talking about applications built as a suite of small services. Each service generally contains its own business function, run in its own context, with its own resources.
Microservices typically have the ability to communicate with other services in a loosely coupled way, often over RESTful APIs. This allows developers to implement each service as its own self-contained action, which provides a lot of flexibility and reuse of developed components.
There are a number of principles that are generally adopted when developing microservices for application design and development. Many of these principles are adopted to ensure that systems are robust, supportable, and can be developed quickly.
Let’s take a look at these architectural principles.
Organized by business functions
The first key principle of microservices is the organization by business function. This principle allows you to slice up the work into potential services that can be composed together to form a business process. For example, a typical banking application might be broken into some of the following microservices:
- Check balance
- Make payment
- Transfer funds
- View transactions
- Authenticate user
One of the important design considerations when using this principle is to ensure that the business function is as generic as possible. For instance, the service “check balance” could be defined as “check savings account balance.” However, if you think of this as a service, this would be too limiting and really the only difference between the two would be the account type that can be passed in as a parameter.
Highly maintainable and testable
The next principle is ensuring that the services are maintainable and testable. This principle can be a little hard to understand, but it is primarily based on the concept of your services being relatively small.
Each service should contain a minimal number of steps while still remaining as generic as possible. This allows your service to be easily understandable, making it a lot easier to maintain. It also simplifies the testing required for the service and, coupled with a test-driven development process, also ensures that the service components can be easily tested.
Trying to develop services free of dependencies is the most challenging aspect of a microservices architecture. There are a number of ways to achieve loose coupling, and the use of a messaging system that implements a publish/subscribe mechanism provides a good way to achieve this.
Allowing services to be independently deployable results in a lot of flexibility when deploying new service components, updating existing components, and isolating components.
Owned by a small team
Finally, each service can also be owned by small teams. Rather than multiple large teams owning large applications, finding the team that supports specific functionality is a lot easier with applications composed of small services.
Benefits of adopting a microservices architecture
Developing software using a microservices architecture practice changes the way historic development practices work. This style of development offers a lot of practical benefits when adopted.
Modularity enables a lot of benefits for large scale applications, particularly in finance. Being able to add, remove, or recompose lines of business and business processes by adding, moving, or removing modular services enables a lot of flexibility and responsiveness.
Having a suite of individually scalable services also allows applications to flex with burst workloads in a cost-effective manner. For instance, if bulk payments are generated or large numbers of users are sending funds, those specific services can scale independently to meet the load, rather than the whole application.
Microservices, by design, have a great affinity with cloud offerings, allowing services to deployed onto a cloud infrastructure using three different models:
- Infrastructure as a Service: You manage services from the operating system up.
- Platform as a Service: You manage services from the container up.
- Serverless: You manage only your services.
Your build and deployment pipelines for services can be vastly improved and automated. Services should minimize changes to their interfaces, allowing changes and updates to occur with almost none of the downtime associated with traditional build and deployment activities.
Microservices support easier troubleshooting. This benefit requires good practices, but essentially it is a lot easier to see when components of your application are misbehaving. Because services are testable and visible, you can see when a service is failing its tests, using too many resources, or generating error logs.
Finally, managing the building of large, complex applications becomes a lot easier. As you go through the sections of your system, you will be defining small, manageable services that allow you to build, test, and deploy portions of your application quickly. As application development continues, much of the work becomes less about developing new services and more about adapting and composing services in different ways.
As mentioned, there are several ways to deploy cloud-based applications that also extend to on-premises and hybrid scenarios.
Traditionally, applications were deployed as a few big components on bare metal servers. You can still do this with microservices, and it may be particularly useful for services used in batch processes. However, most applications built using microservices try to take advantage of being able to scale automatically as required.
Hosting applications in virtual environments is fairly common practice with on-premises deployments. Virtual environments allow a microservices application to scale in some ways, but they’re still not as flexible as other environments. For instance, services used as part of a batch process that can start and scale virtual machines to crunch large amounts of transactions work reasonably well when deployed using virtual environments.
Cloud environments offer a large amount of flexibility when deploying microservices applications, with a number of options around how much of the environment to manage and almost limitless resources to scale individual services. Microservices do really well when deployed to cloud environments.
Running services within containers provide the most flexibility and control, albeit with additional overhead for maintaining and monitoring containers. Containers like Docker provide a self-contained environment for services to run in. Orchestration services like Kubernetes and Docker Swarm allow you to run and scale containerized services across both on-premises and cloud infrastructures, allowing for a truly hybrid deployment model.
For instance, a payment processing service that runs primarily through a batch process might be written in Rust to ensure it runs as optimally as possible.
The other consideration of applications built using a microservices architecture is whether to adopt a truly serverless build leveraging Lambda (AWS) or Functions (Azure). These services allow you to build and deploy services without the need to configure scaling, servers, containers, or other components.
You had a broad look at microservices, their benefits, and how to approach designing and developing applications using this architecture. While they shouldn’t be used for every application, a microservices pattern can add a lot of flexibility for large applications and can really leverage the benefits of cloud services.
If you are looking to adopt this pattern or build your financial application in the cloud, check out the in-depth microservices guidance from AWS (https://aws.amazon.com/microservices/) or Azure (https://docs.microsoft.com/en-us/azure/architecture/microservices/
This article was originally published on the FIS Developer blog.