The era of mainframe, Client-Server, Web, SOA and REST is almost behind us and we are slowly moving towards Microservices. That last one is a hot topic among tech people at the moment. It gets its popularity among developers because it follows a bottom-up approach. As their name suggests, the focus of these tiny and highly decoupled processes are small tasks within complex applications of processors. Let’s take a look into a monolithic application before we discuss this topic any further.
Monolithic application contains many components (modules) that are integrated with each other and included inside the application. A good example is Facebook. Applications of this type are initially very good; however, maintenance becomes an overhead.
It becomes very difficult to make changes, when the components tightly couple over time. Sometimes even the component owner may not be sure about the impact of changes to the application. For each component change there is also a need to deploy everything. Through experience, we have seen Salesforce projects with that nature.
Some call Microservices a practice of SOA doing right. In a way we are not reinventing anything new rather than implementing best design practices. So the idea of Microservices architecture is to divide the application into different services. By definition it should be tiny. But this should be decided by business requirements, domain, ownership and impact, not by technical aspects such as lines of code.
In a nutshell: Microservices are Individual services exposed via REST services. Netflix is a good example of implementing Microservices. One of the important characteristics of Microservices architecture is that each service is individually owned by a small team. Besides, dependencies to other modules should be minimum.
Even though Microservices solves some issues, there are some drawbacks you should consider. Current developer tools are not updated to support complete life cycles of Microservices. Testing, monitoring and debugging issues becomes very complex. Commonly inter service communication is not reliable. So admins/developers need to plan additional resiliency between inter service communications. There is a layer called service mesh. With the help of sidecar concept, users can implement the inter service communications with resiliency.
Asynchronous communication is well suited for a distributed architecture used with Microservice. This can be implemented by appealing to the Event Bus. This also simplifies the inter service communication. With this approach services are not required to call directly other services.
The Salesforce Multitenant Platform (PaaS) makes it possible to speedily deliver robust microservices that match the needs of the larger organization. If an organization is already using Sales and Service Cloud, same data and logic can easily be exposed as rest of the Microservice architecture.
Providing Microservices from Salesforce is straightforward. Standard API is not the best practice since it will change the interface based on internal metadata changes. You can directly use Apex REST to implement Microservices. Salesforce takes care of hosting and scaling for you. This is a super fast and easy development.
Following is a recommended way to implement the Microservice in Salesforce.
- First we can start with the service interface.
- Then we can do the implementation via interfaces. It is good to have service factory pattern to bind the service implementation to the interface.
Asynchronous communications within Salesforce and outside Salesforce microservice can be handled with Salesforce platform events. These events are reliable since it will retry multiple events within a 24 hour window.
Advantages of implementing microservice with Salesforce include updates of the services independently, Salesforce updates the tech stack automatically, fault isolation, options for scaling as Salesforce handles that for you. Use service factory design pattern to implement service discovery of microservice. The main drawback are the Governor limits within the Salesforce platform. However, you can still make it work by processing as little as possible. Lengthy process can be chained with several microservices. It should be noted that JSON processing effects heap allocation badly in Salesforce servers. Authentication with only Salesforce standard mechanism and Internet latency is another issue with this approach.
Heroku
Heroku is a well known platform for your Monolithic or Microservice application. Also, professional developers can code custom microservices in the development language they prefer, including Ruby, Java, JavaScript, C++, Python, and Node.js. Coding can also be done using simple annotations. All this, without needing any complicated middleware. The platform also has an attractive pricing plan. This platform simplifies the spawning of containers with dynos. In addition, with private spaces, users can create their own set of microservices that are on the same subnet and communicated via Http or grpc. With the support of Kafka add-on, users can easily implement pubs-sub models.
Serverless and Microservices
Serverless computing pricing is based on the actual amount of resources consumed by an application. Microservice code can be deployed as Serverless with this execution model in which the cloud provider runs the server, and dynamically manages the allocation of machine resources rather than on pre-purchased units of capacity. However Heroku has fixed dyno prices that needs to be manually adjusted, AWS Lambda is a good example of price based on real usage.
Future
Many organizations are experimenting with Microservices. There are few organizations using it in their production today. However, there are overhead of using this. Since each service is owned forever by a dedicated team there is going to be many teams with different skills for long term. That maybe one of the reasons why Microservices is still not widely adapted.
Conclusion
Microservices is not a silver bullet to solve all the problems. However, if you see a module of your system that frequently needs to change, it can be a good starting point to transform it as Microservice in existing Monolithic application. If you are building a new system you can think about this architecture and design accordingly to the organizational needs. You may ultimately end up with a hybrid (Monolithic with Microservice) which adds value to your business and makes perfect sense.
