Microservices

Communication Technologies: (In a microservices project, you probably be using both.)

Synchronous
Asynchronous

Hosting Platforms:
Virtualisation (using Virtual Machines to host the microservices, running on
hardware which is simulated in software; good for cloning if more instances of the same
service is required; using PAAS; alternatively, create your own cloud infrastructure (e.g.
vSphere); the downsides are that they could me more efficient, take time to setup and to
load, take quite a bit of resource; unique features are taking a snapshot of a VM to restore it
at a later date, or cloning VM; virtualisation is standardised and mature with great tooling
Containers (type of virtualisation; isolate services from each other; single service per
container; less resources than VM; faster than VM; quicker to create new instances; future
of hosted apps; cloud platform support for them is growing; mainly linux based; not as
established as VM (not standardised, limited features and tooling, infrastructure support in
its infancy, complex to setup); Examples are Docker, Rocker, Glassware
Self-hosting (an option for implementing a microservices infrastructure; good if
already existing IT infrastructure with staff; implement your own cloud (virtual platform or
containers); alternatively, if own cloud is too complex, use physical machines/servers;
challenges include long-term maintenance, need for technicians, training, need for space,
scaling is not as immediate)
Registry and Discovery (as demand increases, more instances of the same
microservice needs to be created. Therefore, you need a way of registering these instances
so that they can be discovered by the system. In a self-hosted system, this will be your
responsibility; we need to know where that microservice is (host, port, version); a good way
of doing this is by using a service registry database which on start-up register themselves
and deregister that instance of service on failure; on public cloud platforms this is straight
forward and automatic; on a self-hosted system, options of registry include – self registry or
third-party registration which detects new instances of microservices; after all the services
are registered on a database, how do the clients get to know the locations? – either client
directly connects to the database (client-side discovery) or you use a gateway that all the
clients connect to and the gateway retrieves the locations from the service registry
database (server-side discovery).)

Observable Microservices (to make microservices more observable)

Monitoring Tech (Tools like Nagios, PRTG, load balancers, New Relic; Desired
features are: the ability to gather metrics across servers, with automatic or minimal
configuration, client libraries to send metrics, send and monitor test transactions, send
alerts when things go wrong, network monitoring; standardised monitoring is crucial with a
real-time component
Logging Tech (a number tools act as a portal for logging data – you push the logs at
these tools and these tools store the logging data in a central database; usually comes with
a front-end to look at and query the logging data; vendors are: Elastic Log, Log Stash,
Splunk, Kibana, Graphite; You also need to implement a client logging library which pushes
the log against the centralised tool (e.g. of a vendor is SeriLog); desired features are:
structured logging, logging to work across servers; automatic or minimal configuration; need
for logging a correlation/context ID for transactions to later query them; need for
standardised logging across the system.)

Performance (Available tech to help with microservices meet performance requirements)

Scaling (creating multiple instances of a service or adding resources to existing
services; can be automated or on-demand; PAAS auto-scaling options available; works best
with VM and containers; needs a load balancer such API gateway; When to scale up? When
experiencing performance issues.)
Caching (cashing is a way of detecting when multiple that multiple calls are asking
for the same thing; instead of honouring each request, you honour one and use the same
data to satisfy other requests also reducing the amount of traffic; improves performance by
reducing client calls to services, service calls to databases, and service to service calls;
cashing needs to be simple to setup and manage and avoid any data leaks.)
API Gateway (central entry point into a system for client applications; has load
balancing and caching functionality; provides one interface to many services; helps with
dynamic location of services; gateways can also be configured to route specific calls to
specific instances of a service; can also be configured to look up the location of
microservices in a service registry database; provides dedicated security service.)

Automation Tools (for easy testing and deployment)

Continuous Integration ()
Continuous Deployment ()

Brownfield Microservices (existing system within an existing architecture that needs to be

migrated to a microservices architecture)
Greenfield Microservices (creating a system from scratch)

Brownfield Microservices:
Approach (Analyse code and identify seams – separation that reflects business
domains/functions of the organisation; also identify bounded contexts, i.e. code that
overlaps from one domain/function to another; start modularising the bounded contexts
and move code incrementally to the right target service; tidy up each section per release;
take our time as you don’t want to break the existing system; to validate change, run unit
and integration tests; after every release, we review the code again and refactor again to
make bounded contexts even clearer; the seams are future microservice boundaries.)
Migration (so the code of one business domain/function is in one place and clear
boundaries with clear interfaces are visible; convert these bounded contexts into
microservices – start with one to get comfortable with the tools; think about if you want to
make it switchable which would require two versions of the code; prioritise what to split
first according to risk/tech/# of dependencies…; utilise an incremental approach and make
sure they integrate with the monolithic system; and when both are up and running, monitor
both for impact; also monitor operations that talk to microservices; review and improve
infrastructure; incrementally the monolithic system will be converted.)
Database Migration (so that each microservice has its own database as we want to
avoid shared databases; it is the same approach as to splitting code into bounded context
and identify seams; use API calls that can fetch data for a relationship if a cross-service
requires access to another database; refactor one large monolithic database into multiple
databases; maintain data referential integrity (if for example stuff from one database gets
deleted, it also needs to be deleted from other linked databases); static data tables will be
used within configuration files and made available to each microservice OR create a
separate microservice for a static data table; the same is valid for shared data.)
Transactions (how we need to handle them differently to monolithic systems; they
are useful as the ensure data integrity; transactions spanning multiple microservices are
complex as they are distributed, so difficult to observe/problem solve/rollback as opposed
to monolithic apps; if a transaction fails options are to try again later, abort entire
transaction, or use a transaction manager (two phase commit); disadvantages in using a
transaction manager are reliance, delay in processing, potential bottlenecks, and complex to
implement; when the new microservice is running alongside the monolithic system, the new
MS needs to tell the monolithic system that their part of the transaction is complete by
placing a message in the message queue of the monolithic system).
Reporting (microservices complicate reporting; data is split across many
microservices so no central database with the need to join data across databases in order to
provide the information the organisation needs; it is therefore slower and more
complicated for report development; possible solutions are: dedicated reporting service
that calls other microservices to collect and consolidate the data (not adequate for large
amounts of data or when needed in real time); another option would be a data pump to
pump the data to a central database OR use a consolidation environment (if real-time is no
requirement) for collating all data into a central database perhaps on an over-nightly job;

Greenfield Microservices:
Introduction (applicable to a new project with potentially evolving requirements due
to not fully understood business domains needing to get domain experts involved; System
boundaries will evolve and that is why it is important to understand and collect the
requirements and not focus too much on what microservices are required to address the
overall problem; consider the team’s experience; also is the new system going to integrate
with an existing (microsystem or monolithic) system; the key thing is to push for change
Approach (start off with a high-level design and allow the seams within the system
to evolve; define each high-level area as a module; as the interaction between the areas and
seems become clearer the boundaries of the system will become clearer as well; as our
understanding of these modules become clearer, we refine and refactor our design and if
we further splitting is required, do so; it is these modules that later on become our
microservices; if you find that lots of code needs to be shared between these modules,
consider promoting the code libraries to a service; at each stage we review the microservice
principles and that we also keep the requirements in mind – that we actually deliver what’s
required in terms of customer needs and demand)

Microservice Provisos:
(i.e. what you need to accept before you implement a microservices architecture; if it is the
first microservices project the development times will be longer and cost for training, tools
and new skills is higher; it will also take for the team time to skill up to handle a distributed
system; only with time and experience will they be able to handle distributed transactions
as well as handling reporting in an environment where data is not kept in one place;
because of distributed nature of the system, you may need to invest in extra testing
resource in order to test for latency, performance, and resilience; you also need to ensure
the network is adequate for our software by testing for security, performance, and reliance -
you may find that you have to improve the network infrastructure – this is important since
our software components heavily rely on the network in order to function; we also need to
understand that there will be an overhead – to manage these microservices, we need to
monitor our system for performance issues to avoid any problems; investing in cloud
technologies will make the management of microservices a lot easier; we also need to
accept the fact that applying the microservices design principles overall for an organisation
is a culture change