Microservices

Microservices

Microservices are a common way to build and deploy applications. It’s an architectural style where an application is composed of many distinct parts that work with one another.

The fact that a microservice is deployed as multiple parts means that there is inherently more complexity as deployments need to be coordinated.

Whether or not an application is built as a microservice is not evident to end users. The user experience and functionality would be the same.

The decision to use microservices is driven by internal processes and business requirements.

Benefits

Independence

Teams can work independently as they build and deploy their own applications. A team's applications can typically be deployed independently of other teams' applications.

Frequent Deployments

Applications have a more defined scope. Since they are not bundled with the rest of the business logic, applications can have more frequent releases.

Downsides

Complexity

While a microservice architecture decreases the complexity in a given application, it increases the complexity of the overall system. A system is now composed of applications that are deployed independently of one another. The same applications are built by distinct teams that may not share the same design patterns.

Automation of Build Processes

One of the main roles of a DevOps engineer is to to enable the organization’s developers. This typically involves setting up infrastructure and automating repetitive processes.

Continuous Integration

Continuous Integration (CI), is a form of automation that can help us automate the build process of building Docker images.

A Continuous Integration tool can be configured to detect when applicable changes are made in a code base and then run a predefined set of steps.

Common Patterns

The following are some common patterns of how CI tools are configured with Docker setups:

• Create a GitHub pull request, build the Docker image and push it to a project's test repository in a container registry.

• Make a change in the main branch, build the Docker image and push it to a project's main repository in a container registry.

• Make a change in a main branch, build the Docker image and run integration tests on the built Docker image to track regressions.

• Set up a schedule to run every night to build a new Docker image for unstable builds.

CI Conventions

Triggers

A trigger is an action that makes a build occur. This can be a manual action or it can be an event such as a GitHub commit being pushed.

Variables

Specifying variables in the CI process allows you to inject certain variables into the build. This is often useful for build flags or secrets that are used during the build.

Build Specifications

Build specifications define the actions that a build should perform. Typically, we build an artifact (eg. Docker image) and push it to somewhere (eg. ECR).

Build Logs

In order to debug our build processes, it’s important that we have logs to understand what happened during the build process. Build logs provide a way to troubleshoot.

Continuous Integration (CI) Options

There are a lot of CI tools available. In our lesson, we will be using AWS CodeBuild as our main CI tool.

Many CI tools are being introduced into the industry. There are so many competitive products that trends emerge in what companies decide to adopt. Since there is not as much standardization, it makes more sense to learn something that is simple that provides knowledge that is portable to other applications.

Benefits of AWS CodeBuild

1. Easy to Set Up

AWS CodeBuild is incredibly easy to set up. AWS users can set it up very quickly as the setup is rather simple and involves only a few steps.

2. Integration with AWS

If your infrastructure is set up in AWS, you can take advantage of the many integrations that are available. For example, there is support to use AWS CloudFormation templates or deployments to AWS Lambda.

3. Simple

AWS CodeBuild is that it is incredibly simple and straightforward to set up and use. By understanding how to use CodeBuild, we can build a strong foundation that will help us to quickly adapt other CI tools when needed.

Downsides of AWS CodeBuild

1. Tightly Coupled with AWS

Using AWS CodeBuild to automate tasks outside of your AWS account may be cumbersome. There are built-in triggers to detect changes in GitHub but some more uncommon tasks, such as integrating with other cloud platforms, are not common conventions.

2. Not Popular

While it's not the most popular tool, it has a lot of common conventions, is easy to use, and knowledge of its usage is relatively portable.