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
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
Microservices Design Considerations
Bookmarks our “Session in 2020” page for all upcoming and old sessions of 2020. Let us know which topic you want learn next in ApexHours.
Salesforce Apex Hours