Microservice Approach


The foundation of the Microservices approach is DevOps. Public facing content and component source code are maintained on a Git service where it is continuously updated, rebuilt and pushed to the different layers of the stack.

While public facing web content is pushed to a CDN to ensure quick delivery, services are built and packaged into containers and delivered to a runtime environment such as Podman, K3s or Kubernetes.

Core web and application pages are displayed using pre-rendered content that is fetched from the delivery network, while interactive elements are fetched using client-side JavaScript. Depending on the stack a number of API calls to either private or 3rd party API gateways are made and rendered on client devices.

API Gateway

Custom built components and services are hidden behind an API gateway, which provides a single secure accesspoint for all backend services. The gateway communicates with client devices using a REST API, based on either traditional JSON or more fine grained approaches such as GraphQL.

At the private network facing side the gateway communicates with a fleet of microservice containers, using optimised data exchange formats such as protobuffers.

The gateway handles all incoming requests, translating them to the appropriate protocols and routes them to the appropriate microservices. Service responses are translated back to public facing protocols and delivered asynchronously to end users, ensuring that no component delays can halt or delay the overall process.

Functions and Services

In a full microservice based design every major website or application feature is run as a separate service. Things like user authentication, user comments, shopping cart management, recommended products, analytics and others all run independently, sourcing their data from one or more databases.

The major advantages of this approach are incremental updates and upgrades to individual services, simplified scaling as well as fine grained control. The obvious disadvantage is increased complexity in initial design and deployment. With Coduity by your side however that won’t be a concern.

We offer a fully incremental approach to microservices. Aside from fully supporting 3rd party integrations, we offer options to run hybrid environments. Hybrid deployments allow conventional backend services to keep running, while features and functions are incrementally ported to a microservice architecture if and when the situation calls for it.


Where the microservices architecture truly shines is distribution. Conventional backend services are more suitable for vertical scaling, meaning adding more and more capacity to a limited number of servers. Microservices are designed to be stateless, allowing for horizontal scaling. Horizontal scaling not only allows a virtually infinite number of servers (or containers) to share in the workload, it allows for globally distributed deployments.

While pre-rendered content such as HTML and media are relatively easy to distribute by having copies available in different locations around the world and ensuring shortest path delivery, the same cannot be said for dynamic or interactive content.

Using modern database solutions that support sharding and geo-clustering, microservices and API gateways can be distributed globally. With Coduity microservices your business can deliver lightning speed content to customers, both pre-rendered and dynamic database driven content alike. The importance of which cannot be overstated as customers expect the best and won’t stand for loading screens.

Frequently Asked Questions

What are the advantages and disadvantages of microservices?

The primary disadvantage of developing applications as a fleet of microservices is complexity. One could say that the complications of traditional (monolithic) and modern microservice application development are opposites.

Microservices are considered more complex to develop as well as requiring a more complicated infrastructure from which to operate. Once achieved however, further development and scaling are relatively straightforward.

Monolithic applications are considered to have a basic and straightforward development and infrastructure, but further development and scaling become increasingly complex. Scaling monolithic applications is further limited by the availability of hardware technologies.

In other words, it is cheaper to get started with a monolithic application but more expensive to maintain and grow it. It is more expensive to build and launch a microservice based application, but cheaper to maintain and grow it.

That is at least the conventional belief with microservices v monolithic applications, but not with Coduity. Our microservice based application are built for the price of monolithic applications, while maintained and scaled for microservice prices.

Can Coduity convert our application to a microservice deployment?

Certainly. We do so often and in a modular way. Rather than insisting that the whole of your application be migrated at once, we instead focus on those features that would stand to benefit the most. Incremental migration when needed, not when believed to be needed.

What kind of infrastructure would we require?

We generally deploy our microservice solutions on Kubernetes using either K3s or K8s, optionally in conjunction with Knative. This is not something to worry too much about in advance however as we always include infrastructure designs in our offerings. Rest assured that it will be based on free and open source software that is vendor independent at the infrastructure level.

Other Solutions

Let's start with a free analysis and a quote