A sample set of applications for a mythical business unit to demonstrate modern application development and DevOps practices.
The set of business applications revolves around retrieving data from external APIs and relaying it to customers, collecting API usage, and presenting basic API usage aggregates. The external API of choice is XKCD. This unrestricted simple API is perfect for a sample application. The application modules are:
- api - external API, which calls public XKCD API and relays data
- data-model - common objects utilized by components
- flyway - creation of database schema for usage reporting
- perf-tests-api - Gatling performance tests for
apiandstats-api - stats-api - external API, which returns aggregate
apiusage stats - stats-reporting - reporting tool, which saves raw
apiusage into the database of choice.
Several applications are chosen to reside in a monorepo not be confused with a monolithic application. Monorepo facilitates easy collaboration between teams and integration, atomic commits, code refactoring.
Common build aren't always geared the most to support monorepos. Building tens to thousands of projects residing in a common codebase from scratch + running all the test would take a prohibitively long time. Incremental build strategies come to the rescue. Apache Maven, the most popular build tool for the backend applications, has only rudimentary incremental build capabilities. Specialized build tools like Bazel allows for fast incremental builds on a large scale using distributed build cache. However, IDE support and overall interoperability with test and deployment tools might lack behind for such specialized tools, which are not open-sourced. In turn, Gradle is a good bet for supporting the monorepo. Incremental build capabilities of Gradle including incremental test execution are advancing with each version. Gradle now supports distributed HTTP build cache, which allows to effectively compete with Bazel in incremental build performance.
Deployment with Kubernetes is chosen to allow for great versatility and ability to deploy on various on-prem or cloud platforms. Pain points from the earlier days of Kubernetes gave way to wide adoption with substantial community support. One of pain point of Kubernetes, non-trivial cluster administration with the control plane, can be effectively delegated to a cloud platform of choice (e.g., on AWS) or be encapsulated into a large solution like OpenShift. Cloud-native deployment on Kubernetes is our bet for a portable, reproducible, and scalable deployment. We adopt Elastic Kubernetes Service (EKS) on AWS for this project.
The overall DevOps strategy includes
- AWS native build / deploy tools CodeBuild and CodePipeline,
- AWS deployment orchestration with CloudFormation,
- application deployment into AWS EKS driven by Kubernetes templates,
- consolidation of infrastructure as code concept with Ansible tool.
AWS Cloud Development Kit and its extension for Kubernetes provide a potential new alternative to the above practices.