CoWorks is a unified serverless microservices framework based on AWS technologies
(API Gateway, AWS Lambda),
the Flask framework and the Airflow
plateform.
Small technical microservice
Each atomic microservice (defined as classTechMicroService) is a simple python class deployed as a serverless
AWS Lambda and can be called synchronously and asynchrously.
Functional business service
Composition of microservices (defined with the @biz decorator) is performed over the tech microservices and
constructed by Airflow workflows.
In short, the microservice architectural style is an approach to developing a single application as a suite of small services,
each running in its own process and communicating with lightweight mechanisms.
In Microservice Architecture (Aligning Principles, Practices, and Culture),
authors M. Amundsen, I. Nadareishvili, R. Mitra, and M. McLarty add detail to the definition
by outlining traits microservice applications share:
Small in size
Messaging enabled
Bounded by contexts
Autonomously developed
Independently deployable
Decentralized
Built and released with automated processes
In CoWorks, microservices are serverless functions over APIs.
Small in size
Simply implemented as a Flask python class.
Messaging enabled
API Gateway request-response managed services.
Service oriented
Technological service by Flask entry, biz service by Airflow workflow.
CoWorks microservices are divided in two categories :
Small technical microservice
Implemented as a simple AWS Lambda function, this kind of microservice is dedicated to technical
operations over a specific service. Technical miscroservice should be stateless.
Functional business service
Implemented by Airflow workflow, this kind of microservice allows non programmer to construct
functional business workflows.
Distinction between technical microservice and business service is based not only on granularity size but also:
A TechMicroservice should mainly be used as receivers of orders coming from @biz.
A @biz represents a logical workflow of actions while a TechMicroservice represents a simple concrete action.
A TechMicroservice is an independant microservice while a @biz is connected to event handlers (cron, notification, event, …).
A TechMicroservice is more a handler pattern and @biz a reactor pattern.
Like any model of software architecture, it is very usefull to have complementary tools for programming, testing,
documenting or deploying over it.
The main advantage of using CoWorks is its ability to defined those tools, called commands, directly in
the microservice code.
Predefined commands like run (defined by the Flask framework) or deploy are provided,
but you can redefined them or creates new ones like for documentation or testing.
The CoWorks microservice architecture provides some best pratices for code organization and directory structure.
Indeed it’s so easy to start in serverless project, it’s also easy to start moving the wrong direction.
API and Lambda organization
With AWS API a single Lambda function handles a single HTTP verb/path combinaison. For Rest API it is better to have
a single lambda function to handle all HTTP verbs for a particular resource.
CoWorks regroups all microservice entrypoints into one single class. And a class is the resource granularity
for the API.
For example, following the CRUD design :
The significant benefit of this architecture is that the number of Lambda functions is drastically reduced over a
one to one CRUD event mapping.
Configuration
CoWorks differenciates two kind of configurations:
Automation and command configuraton
Execution configuration
For those who are familiar with the Twelve-Factor App methodology,
the CoWorks configuration model correspond exactly
with the strict separation of config from code.
More precisely:
The project configuration file : Use a declarative format for setup automation, to minimize time and cost for new developers joining the project
The dotenv file : Env vars are easy to change between deploys without changing any code
