In the first post of this series, I described the motivations and goals of CommerceOS. I stated that CommerceOS is eBay MP version of Micro Services, It is a portfolio of services (RESTful and deployed in the cloud) that enable developers to build applications that facilitates commerce among people and/or entities, on any device, any language, rapidly, economically and securely.
In this post I will start describing some technical details, best practices and what we learned from building a service portfolio at scale.
The easiest way to start describing CommerceOS is with this basic picture illustrating the over all topology of the system
This diagram shows a high level logical architecture of the ecosystem and its main components
- Applications: this includes applications on mobile, and all other devices, web apps as well as 3rd party applications, merchant and partners back ends. etc. Basically all consumers of CommerceOS portfolio. The number of applications using CommerceOS services are in the range of 10s of thousands and those include eBay applications (1st party) as well as partners and 3rd party apps
- Services Portfolio: These are services and business capabilities that enables marketplaces operations as well as Commerce primitives used to build any commercial app. Examples are Listing, Checkout, Order Management, Listing Details, Watch List, Cart etc. These services are often (but not always) multi-tenants. Collection of these services is called "The Portfolio", The number of services in CommerceOS portfolio is the range of 100s built by team across the globe.
- Shared Services: core platform capabilities such as Identity & AM, Security Token Services, Session, Tracking, Messaging (of all types) etc.
- API Middle Tier : Part of "shared services" is a middle tier that mainly functions as simple router connecting API request to internal services implementing them.
CommerceOS is structured into five major activity streams (and similar organization structure), each essential to build and operate a Microservice ecosystem at scale. The tracks are
1- Standard and Patterns
2- Services Portfolio
3- Foundations and Shared Services
4- Evangelism and Advocacy
5- Governance, Metrics and Measurements
Standards, Pattern
The first observation about an ecosystem with 1000s of apps and 100s of services is that if key aspects of service interface and implementation - such as error handling, tracking, identity internationalization, version policy, monitoring, billing etc. - are left to each service team to decide, developing an application that consumes on average 20-50 services will be extremely difficult and unproductive task. This approach may also creates legal liability (dealing with financial or personal data). A decision we made early on, was to formally define (and carefully document) standards that make all components work together. This may not be what you expect from a Micro service portfolio, but we learned that formal documenting of standards (and versioning them) is extremely valuable both for system developers who would be implementing those standards in form of run time libraries and shared services as well as service and application developers to learn about the portfolio in general. See part III for more detailed on standardsFoundations and Shared Services
A portfolio of services requires three major foundation pieces- Run time libraries for services (in supported tech stacks)
- Shared Services that are used by the entire portfolio (and you really don't want replication of any of its functionalists), services such as Identity and Access Management, Caching, Messaging, Crypto Services, config, registry and discovery, content management)
- Productivity Tools: Vital for operation of portfolio are tools (and dash boards) for monitoring, recovery, synchronization, life cycle management, learning and exploration tools etc.
See part IV for more information
Service Portfolio
This is the actual portfolio of business capabilities, the services are designed and built by de-centralized (and global) services teams - they are often between 3-10 people, and they are free to use any technology stack they see fit - of course if they use the eBay standard Java/Spring based framework (called Raptor) they get a lot of functionality for free - but they don't have to. Services must publish their descriptor formally and some elements of their type spaces (such as User, Listing, Order, Cart, Claim, Product etc.) are standardized (i.e. they are part of a Common Type Space) - services also need to declare events they produce.
Evangelism and Advocacy (E&A)
This may be one of the most significant, yet poorly understood, area of any service portfolio management. People often view this as "soft skill" area. However, they are vital to BOTH adoption and evolution of service portfolio. Let's see what they are
- Evangelism: Main goal is to make sure application developer community (especially internal one) know all capabilities in the portfolio and how to use them. It includes documentation, sample codes, sample requests sets (especially for edge and error cases) as well as basic performance characteristics of a service. Without proper evangelism, developers will not know what capabilities exist, and how to use them properly, as the result, they will re-build the same capability (often with slightly different name, semantics and implementation).
Advocacy can be thought of as the reverse of evangelism - its primary goal is to make sure services cover all the right capabilities application developers need. Through advocacy (and collecting requirements) - we learn whether we need to introduce (or promote) a new type to our common type space, or whether we need a new service (such as integration with certain data provider - such as phone IMEI or business address provider).
Both E&A are critical in re-use at scale - re-use (especially at the domain capability layer) is not developers' natural reaction. The higher you are on the stack, the tougher the re-use become. It is less likely that a team (or engineers) rebuild JVM, or a messaging protocol, but business abstraction such as Identity, Cart, Order, Search Result, Listing, Invoice etc. as well as processes that operate on the, are duplicated all the times. E&A is the key to get some level of re-use at the business domain.
Governance, Metrics and Measurements
The last major area of activity for CommerceOS is Governance, Metrics and Measurements. A lot of people believe that no governance should be required in developing a Micro service portfolio, this only leads to chaos - particularly for application developers that often consume a large number of services. A more sensible suggestion is "decentralized governance". This sounds like a good idea, but the devil is in the details. CommerceOS adopted a light - but well defined - governance model and processes that enables it. I fully realize that this may not be a popular concept in today's environment driven by buzzwords such as "autonomy" and "agility", however my personal experience is that
- Right level of governance makes everyone job mush faster and less painful
- Process has to be transparent, objective and driven by an explicit and measured SLA - what people hate is arbitrary process run by "people who think they know more than you do".
Having said that, CommerceOS defines processes to govern three aspects
- Adding a service into CommerceOS portfolio (or deprecating of a service)
- CommerceOS Common Type Space
- Adoption of an standard or pattern into CommerceOS
Each process is well defined and has largely objective criteria.
See part V for more details.
In part III, I will go over the standards and patterns that make all services and apps interoperate successfully, Part IV focus on Foundations and Core Services and part V talks a bit about processes and measurements.
0 comments:
Post a Comment