The number of microservices running in enterprises increases daily. As a result, service composition, governance, security, and observability are becoming a challenge to implement and incorporate. A “cell-based” architecture is an approach that can be applied to current or desired development and technologies to address these issues. This technology-neutral approach helps cloud-native dev teams become more efficient, act in a more self-organized manner, and speed overall release times. In this talk, Asanka will introduce the "cell-based" architecture, which is decentralized, API-centric, cloud-native and microservices friendly. He will explain the role of APIs in the cell-based approach, as well as examine how real applications are built as cells. Asanka will explore the metrics and approaches that can be used to measure the effectiveness of the architecture and explore how organizations can implement the cell approach.

1. Asanka Abeysinghe
Cell-based Architecture
Decentralized Architecture Pattern for Cloud-native Applications
Chief Technology Evangelist (former Deputy CTO)
WSO2 Inc.

2. 2019
1997 2003
Architect
2012
VP Solutions
Architecture
2001 2008
Director
Solutions
Architecture
Deputy CTO
Open Source
Distributed Computing
Programmer
COBOL
OLE, OLE2
COM, COM+
DCOM
CORBA
Java Developer
J2EE
MMS286-DX4
Eventing
FIX
HL7
CONNECT-health
Global architecture team
500+ customers
Champions program
Chief
Architect2005
QSP
AR
Trusted advocate
Game hacker
C++ programmer
Age-16
Hedge fund tools
Ref. Architecture
Ref. Methodology
Evangelize
2018
Middleware Developer/Architect
Entrepreneur
Chief Technology
Evangelist
2020
Connecting humans & technology
Architecting the transformation

3. Objectives
#1 why: a new pattern
#2 how: created the pattern
#3 what: is Cell-based architecture

4. picture credit: https://www.flickr.com/

5. Motivation

6. Centralized & Layered
picture credit: https://www.flickr.com/photos/kaktuslampa/

7. picture credit: https://www.flickr.com/photos/69929929@N06/
Powerpoint Architects

8. picture credit: https://www.flickr.com/photos/johnerlandsen/
Reality of the Enterprise

9. Brownfield > Greenfield
picture credit: https://www.apstra.com/home/landscape-of-meadow-field-with-the-changing-environment-2/
Legacy, monolithic Microservices, sprawl

10. Reference Implementations
picture credit: https://www.marinersmuseum.org/

11. picture credit: http://unlocked.footlocker.com/
Underutilization of the Technology

12. Gap: architecture | development | deployment
picture credit: https://www.flickr.com/photos/28994379@N02/

13. picture credit: https://www.solarpowerworldonline.com/2017/07/georgia-contractor-sells-farmers-solar-tough-market/
Dependency management

14. picture credit: https://www.flickr.com/photos/tiocfaidh_ar_la_1916/
Architecture Patterns

15. Timeline

16. Background: Layered Architecture

17. picture credit: https://www.flickr.com/photos/23119666@N03/
A platform with an agile team
100 APIs, 60 message flows, 80 services, n DBs
Multi-tenanted, 3 active tenants
First release after 3 years

18. picture credit: https://www.flickr.com/photos/imcountingufoz/
Rise of Microservices

19. Pragmatic Microservices
Netflix: APIs
Uber: Edge Gateway
eBay: API Facade
Gartner: Mini Services

20. Background: Layered Architecture with MSA

21. Background: Segmented Architecture
BS-1 BS-2 BS-n
G-1 G-2
US-1 US-n

22. Platform of Platforms
Platform (shared capabilities)
Project1
Project2
Project3
Projectn
Platform (shared capabilities)
Project1
Project2
Project3
Projectn
Platform (shared capabilities)
Project1
Project2
Project3
Projectn
Platform (shared capabilities)
Project1
Project2
Project3
Projectn
CI/CD
User
Store

23. picture credit: https://www.flickr.com/photos/ableman/

24. Making of……
picture credit: https://commons.wikimedia.org/wiki/User:Frank_Schulenburg CC BY 3.0

26. Building the
Concept

27. Business vs technical services
picture credit: https://www.flickr.com/photos/arpadlukacs/

28. Service: Technical definition
A code exposes through an
interface that describes a
collection of operations that
are network accessible using
a standardized messaging
protocol.

29. Service: Business definition
Software components that
can be spontaneously
discovered, combined, and
recombined to provide a
solution to a business
problem.

30. Microservice: Technical definition
A microservice must have a
single purpose and be loosely
coupled in design and
deployed independently of
other microservices.
"Micro" is a concept of scope
rather than size.

31. Microservice: Business definition
Microservices is an approach to
application development in
which a large application is built
as a suite of modular
components or services.
These services are built around
business capabilities.

32. Group of (Micro)services

33. The cell is the basic structural,
functional, and
biological unit of all known
living organisms

34. Cell-based Architecture

35. Component: Atomic Units
A component represents a
process or business logic
running in a container,
serverless environment, or an
existing runtime. A component
is designed based on a specific
scope, which can be
independently run and reused
at the runtime.

36. Cell: Units of Enterprise Architecture
A cell is a collection of
components, grouped from
design and implementation
into deployment. A cell is
independently deployable,
manageable, and observable.

37. Cell:Component
1:M
1:1

38. Connected Cells
picture credit: https://www.medicalnewstoday.com/

39. Control Plane:
- Signaling of the network
- Makes decisions about the traffic flow
Data Plane:
- Forwards traffic between hops
- Takes data packets
picture credit: https://www.flickr.com/photos/teflon/
Management Plane:
- Configure
- Observeabiltty, Monitor

40. Inter and Intra Cell communication
Local-mesh
Global-mesh
DP- data plane
CP- control plane
MP- management plane

41. Connected Cells
Cell gateway (ingress)
Sidecar (egress)
Adaptor (egress)
Ambassador (egress)

42. API-first Architecture
picture credit: https://www.flickr.com/photos/hugh_nelson/

43. API-first Architecture Pull APIs
- RESTful HTTP, gRPC
Push APIs
- Events JMS, AMQP, SMTP
- Streams Kafka, MQTT

44. Gateway Pattern
picture credit: https://www.flickr.com/photos/ell-r-brown/

45. Automated Governance (Re)-enables Flow
Policy Store
(Registry)
Observability
(Monitoring/
Analytics)
Policy
Enforcement
(GW)
Automated governance is made
of three things:
A source of truth:
Policy store/registry
Enforcement of the policy
Gateway or plugin attempting to keep
the desired state
Observability
How close to the desired state are we?

46. Security of Cells

47. Developer Experience (DX)
of a Cell

48. Creating Cells
Brand new Cell
Existing (micro)services
Update an existing Cell
Create a new version

50. Lifecycle of a Cell

52. picture credit: https://www.flickr.com/photos/rincon_de_lula/

53. Structured Agility
Versioned Components
Versioned Cells
Dependency managed
Autowired
Reusable
Enhanced MSA & CNA

54. Cell-based Enterprise
Architecture

56. Cell Types
Cell Type Components
Logic Microservices, Functions, MicroGateways, lightweight storages
Integration MicroESB or other integration microservices, lightweight storage and/or cache
Legacy Existing systems, legacy services
External SaaS and partner systems
Data RDBMS, NoSQL, File, Message Broker*
Identity IDP, user stores
Channel Web Apps, IoT, mobile apps

57. Reference Implementation L0

59. Reference Implementation L1

61. Human-centric Architecture
picture credit: https://www.vertoanalytics.com/human-vs-data-centric-marketing/

62. Cells and Cellular Organizations

63. https://www.forbes.com/sites/forbestechcouncil/2020/06/29/the-cellular-enterprise/

64. https://nordicapis.com/what-is-cell-based-architecture/

65. picture credit: https://www.flickr.com/photos/woordenaar/
Cell Boundaries

66. Defining Cell boundaries
The design of systems has always required an approach to the clustering of functionality, and
it remains an open Computer Science problem - so don't expect a definitive answer!
The number of component-component connections within a cell should be higher than the
number that crosses the cell boundary.
Other approaches such as Domain-driven Design (DDD) may help, but fundamentally the cell
model is there to provide team boundaries.
Hence the size of a cell should be based on the size, responsibility, and output of a team
- and the size and output of a team based on team concepts.
Cell-based architecture aims to create business focussed architectural constructs that can
reuse at a higher level, so naturally organizing the teams and cells around business functions
is essential.

67. Measure the success
picture credit: https://www.marketingdonut.co.uk/direct-marketing/running-a-direct-mail-campaign/getting-the-measure-of-your-marketing

68. https://www.tasktop.com/blog/5-best-metrics-youve-never-met/
https://dzone.com/articles/reducing-mttr
Mean Time to Repair

69. Self-contained
Deployable as a unit
Independently elastic
Local data & control plane
Summary: Cell

70. Decentralized, MSA, Cloud-native
Technology neutral
Human-centric
APIs as products
Summary: Cell-based Architecture

71. Contribution: walk the talk
picture credit: https://www.omgubuntu.co.uk/2018/06/microsoft-buying-github

72. picture credit: https://www.flickr.com/photos/infomatique/
Invitation to consume and contribute
https://github.com/wso2/reference-architecture
https://github.com/wso2/reference-methodology
https://ballerina.io
http://wso2.com
http://cellery.io

73. @asankama
THANK YOU
https://www.linkedin.com/in/asankaabeysinghe/
asankaa AT wso2.com