

Extracting Microservices from your Monolithic org: Strategies & Tactics
Breaking up a large, monolithic org can be a challenge. With the push to packaging, however, it’s vital. Attendees to this session will learn how to identify and extract microservices from their monolithic org. We’ll be investigating a real-life example, and pulling out a micro service from a large org.
Attendees will walk away knowing strategies and tactics for breaking up a large org into microservices :
- How you chose this bit of the app to abstract to a MS
- Show the connecting points – data in and out
- Discuss the options for interaction.
We’ll be doing this through a series of slides, and accompanying code walk throughs.
Evolution of a Salesforce Org
Salesforce is a platform for developing Enterprise Applications

Salesforce has evolved from being a CRM to a platform of choice for building Enterprise Applications. Initially, 99% of the applications built are ancillary to the fundamental objects of Salesforce. And then we begin extending this fundamental functionality with all kinds of solutions from the AppExchange market place
Process builders and validations and they don’t tell us and unit tests fail. Continuing with the journey of customization, we then begin adding code. And then we add more code to unit test the existing written code and deploy.
We keep doing this over and over with multiple different teams until the org is a fragile house of cards that comes crumbling down even when a slight modification is required. Congratulations you have built a Monolith
All this fragility and uncertainty causes stakeholders to become MAD sending sparks flying around the room. MAD I am referring to the Monolithic Architecture Despair
MAD – Monolithic Architecture Despair

Tight Coupling – As a result of the heavy interdependence between the components of a monolithic architecture changes in 1 component requires a change in many
Ripple Effect – The cohesion between components also propagates like ripples in water which makes deploying complex and difficult since everything needs to be deployed
Since the monolithic design is usually committed to a single stack, it hinders scaling development. This restricts the flexibility of choosing the befitting platform to get the job done.
Anatomy of a Microservice
Decoupled units of work responsible for delivering specific functionality

- Microservices is a progeny formed through the procreation of Layered Monolithic Architecture + Distributed Service Oriented Architecture
- Isolation – Key aspect in the microservices pattern is isolation of responsibilities through formation of service components which deliver a specific functionality
- Service Components & Modules – Each service component delivers a specific business functionality and comprises of multiple modules (classes) as well as objects. With the nature of the Salesforce platform, it is generally extremely difficult to isolate the database across the applications on the platform.
- However, clear ownership of objects can be determined based on the specific business functionality being delivered.
Key Principles of Microservice Design
ROLID

Resilient – Designed for failure and has the ability to resurrect from a failure
Orchestrated Comm – Communication between the components should be orchestrated via HTTP/REST or Async messaging only.
Loosely coupled – Decoupling enables single point of failure and offers significantly reduced maintenance
Isolated – Responsible for a specific functionality or a process thus offering better testing capability
Diverse – No commitment to a single technology stack
Microservices in action

Financial firm providing wealth advisory to customers through a monthly recurring subscription based model and uses Salesforce. Want to learn more check this recording
Recording
Microservices Design Considerations
Consideration | Microservices | Monolith |
Implementation Complexity | NO | YES |
Fault Tolerance | YES | NO |
Application Maintenance | YES | NO |
Technology Stack | Diverse | Single |
If you are new in Salesforce. Please check our free Salesforce Admin and Salesforce Developer training. Subscribe to the channel if you haven’t already
Thanks,
Salesforce Apex Hours
Hi Amit,
Thanks for posting great content. This is the question for Jigar. I still don’t understand how micro services used in deployment. I know he answered that question by saying we only deploy specific service while other services can still stay up. Isn’t pattern same to how we currently use monolithic pattern where we have separate classes for each chunk of business process or service and thus deploy that particular class. Can you pls shed some more light on this please.
Thanks!
Amit,
The presentation has links to references, can you share the ppt? or the reference links?
thanks,
I need to check if I still have presentation.