Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of services that are
Highly maintainable and testable
Organized around business capabilities
Owned by a small team
The microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications. It also enables an organization to evolve its technology stack.
What makes Microservice different from CI/CD?
Implements a single task within a domain bounded context — meaning that there are many more separate code units to be managed.
Is loosely-coupled making use of little or no knowledge of the definitions of other microservices and communicating by message passing rather than RPCs, function calls or method calls — meaning that it can be deployed individually rather than in a larger executable.
Is autonomous and can be developed and modified with less coordination among different development teams — reinforcing the requirement that it be small and focused on a single task.
Is independently deployable and can be individually tested, rolled out, and rolled back without impacting other microservices —meaning that it must be testable alone, without an enabling framework, and must be deployable in a cloud container. Deployment, operation, and monitoring are usually best managed through a container orchestrator like Kubernetes.
CI/CD is a method to frequently deliver apps to customers by introducing automation into the stages of app development. The main concepts attributed to CI/CD are continuous integration, continuous delivery, and continuous deployment. CI/CD is a solution to the problems integrating new code can cause for development and operations teams (AKA "integration hell").
CI/CD introduces ongoing automation and continuous monitoring throughout the lifecycle of apps, from integration and testing phases to delivery and deployment. Taken together, these connected practices are often referred to as a "CI/CD pipeline" and are supported by development and operations teams working together in an agile way with either a DevOps or site reliability engineering (SRE) approach.
Automated testing enables continuous delivery, which ensures software quality and security and increases the profitability of code in production.
CI/CD pipelines enable a much shorter time to market for new product features, creating happier customers and lowering strain on development.
The great increase in overall speed of delivery enabled by CI/CD pipelines improves an organization’s competitive edge.
Automation frees team members to focus on what they do best, yielding the best end products.
Organizations with a successful CI/CD pipeline can attract great talent. By moving away from traditional waterfall methods, engineers and developers are no longer bogged down with repetitive activities that are often highly dependent on the completion of other tasks.
How It works:
If an Organization is set up to merge all branching source code together on one day, the resulting work can be tedious, manual and time-intensive. When developers working in isolation makes changes to an application, there is a chance it will conflict with different changes being simultaneously made by other developers. This problem can be further compounded if each developer has customized their own local integrated development environment (IDE), rather than the team agreeing on one cloud-based IDE.
Continuous integration (CI) helps developers merge their code changes back to a shared branch, or "trunk," more frequently—sometimes even daily. Once a developer’s changes to an application are merged, those changes are validated by automatically building the application and running different levels of automated testing, typically unit and integration tests, to ensure the changes haven’t broken the app. This means testing everything from classes and function to the different modules that comprise the entire app. If automated testing discovers a conflict between new and existing code, CI makes it easier to fix those bugs quickly and often.
Less bugs get shipped to production as regressions are captured early by the automated tests.
Building the release is easy as all integration issues have been solved early.
Less context switching as developers are alerted as soon as they break the build and can work on fixing it before they move to another task.
Testing costs are reduced drastically – your CI server can run hundreds of tests in the matter of seconds.
Your QA team spend less time testing and can focus on significant improvements to the quality culture.
Your team will need to write automated tests for each new feature, improvement or bug fix.
You need a continuous integration server that can monitor the main repository and run the tests automatically for every new commits pushed.
Developers need to merge their changes as often as possible, at least once a day.
Following the automation of builds and unit and integration testing in CI, continuous delivery automates the release of that validated code to a repository. So, in order to have an effective continuous delivery process, it’s important that CI is already built into your development pipeline. The goal of continuous delivery is to have a codebase that is always ready for deployment to a production environment.
In continuous delivery, every stage—from the merger of code changes to the delivery of production-ready builds—involves test automation and code release automation. At the end of that process, the operations team is able to deploy an app to production quickly and easily.
The complexity of deploying software has been taken away. Your team doesn't have to spend days preparing for a release anymore.
You can release more often, thus accelerating the feedback loop with your customers.
There is much less pressure on decisions for small changes, hence encouraging iterating faster.
You need a strong foundation in continuous integration and your test suite needs to cover enough of your codebase.
Deployments need to be automated. The trigger is still manual but once a deployment is started there shouldn't be a need for human intervention.
Your team will most likely need to embrace feature flags so that incomplete features do not affect customers in production.
The final stage of a mature CI/CD pipeline is continuous deployment. As an extension of continuous delivery, which automates the release of a production-ready build to a code repository, continuous deployment automates releasing an app to production. Because there is no manual gate at the stage of the pipeline before production, continuous deployment relies heavily on well-designed test automation.
In practice, continuous deployment means that a developer’s change to a cloud application could go live within minutes of writing it (assuming it passes automated testing). This makes it much easier to continuously receive and incorporate user feedback. Taken together, all of these connected CI/CD practices make deployment of an application less risky, whereby it’s easier to release changes to apps in small pieces, rather than all at once. There’s also a lot of upfront investment, though, since automated tests will need to be written to accommodate a variety of testing and release stages in the CI/CD pipeline.
You can develop faster as there's no need to pause development for releases. Deployments pipelines are triggered automatically for every change.
Releases are less risky and easier to fix in case of problem as you deploy small batches of changes.
Customers see a continuous stream of improvements, and quality increases every day, instead of every month, quarter or year.
Your testing culture needs to be at its best. The quality of your test suite will determine the quality of your releases.
Your documentation process will need to keep up with the pace of deployments.
Feature flags become an inherent part of the process of releasing significant changes to make sure you can coordinate with other departments (Support, Marketing, PR...).
The Tech Platform