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 :

1. How you chose this bit of the app to abstract to a MS
2. Show the connecting points – data in and out
3. 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

1. Microservices is a progeny formed through the procreation of Layered Monolithic Architecture + Distributed Service Oriented Architecture
2. Isolation – Key aspect in the microservices pattern is isolation of responsibilities through formation of service components which deliver a specific functionality
3. 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.
4. 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

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