Change release date to July of 2021
This commit is contained in:
8
radar/2021-07-01/adr.md
Normal file
8
radar/2021-07-01/adr.md
Normal file
@@ -0,0 +1,8 @@
|
||||
---
|
||||
title: "ADR"
|
||||
quadrant: methods-and-patterns
|
||||
ring: adopt
|
||||
---
|
||||
|
||||
[ADRs](https://adr.github.io/) have proven to be a useful tool for documentation and are commonly used in
|
||||
our organisation. We therefore promote it to the "adopt" ring.
|
||||
12
radar/2021-07-01/akeneo.md
Normal file
12
radar/2021-07-01/akeneo.md
Normal file
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: "Akeneo"
|
||||
ring: adopt
|
||||
quadrant: tools
|
||||
featured: false
|
||||
---
|
||||
|
||||
We continue to use Akeneo with a variety of customers to store and process product data in a standardized format. It is the de facto standard for open source PIM's and therefore an integral part of our e-commerce solutions.
|
||||
|
||||
In the meantime, Akeneo has been continuously developed and offers many new features that further facilitate product data collection.
|
||||
|
||||
The recent switch to Elasticsearch and an update of Symfony improved runtime behaviour as well as scalability for future-prove use. Support for the latest release of PHP 8 is upcoming.
|
||||
12
radar/2021-07-01/angular.md
Normal file
12
radar/2021-07-01/angular.md
Normal file
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: "Angular"
|
||||
ring: adopt
|
||||
quadrant: languages-and-frameworks
|
||||
---
|
||||
|
||||
Actually in version 11 Angular has become an adult SPA framework with much faster build time and significant smaller production builds.
|
||||
Updating to newer versions has become mostly a "no-brainer" which helps us to integrate the latest community bug-fix & improvements on a friday during a cup of coffee.
|
||||
Angular ships as a fully integrated development platform from scaffolding, code generation, routing, guarding, unit/e2e-testing, multi-language builds (i18n) and stable dev/build processes and keeping it extensible at the same time.
|
||||
This holistic nature of Angular makes it in the beginning way more difficult to learn but once understood it's a great candidate to go very fast into "requirement implementation" aka providing early value rather than library wiring.
|
||||
Beside the existing telco-industry projects we've actually also chosen Angular for resource critical industry 4.0 / embedded projects.
|
||||
Here we've selected Angular beside the performance aspects to fulfill requirements like adaptive multi device support (custom hardware buttons, tablets and laptops) on the one hand and on the other hand to reduce the risk loosing time by having too many self-managed external dependencies.
|
||||
9
radar/2021-07-01/apicurio.md
Normal file
9
radar/2021-07-01/apicurio.md
Normal file
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: "Apicurio Studio"
|
||||
ring: trial
|
||||
quadrant: tools
|
||||
---
|
||||
|
||||
[Apicurio Studio](https://www.apicur.io/studio/) is a browser-based, open-source API design studio. It can be used to create or modify APIs using the [OpenAPI specification](https://swagger.io/specification/). The visual editor supports collaborative development and allows to easily define example responses matching incoming requests.
|
||||
|
||||
At AOE, we use Apicurio Studio in conjunction with [Microcks](https://microcks.io/) as part of our API-first development approach. While specifying an API, a corresponding mock server can be set up with a single mouse click. The frontend and backend parts of an application can then be developed independently by using the mock server and the API specification generated by Apicurio Studio.
|
||||
13
radar/2021-07-01/apm.md
Normal file
13
radar/2021-07-01/apm.md
Normal file
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: "Application Performance Management"
|
||||
ring: adopt
|
||||
quadrant: methods-and-patterns
|
||||
|
||||
---
|
||||
|
||||
Application performance management (APM) enables to predict and prevent performance issues before they impact your users or your business.
|
||||
APM solutions help organizations to ensure that applications meet performance, availability and user experience expectations.
|
||||
This can be achieved by measuring application performance, providing visibility into performance issues, alerting developers and administrators when performance problems appear, and allow analysing how reliable an improvement is compared to a previous state.
|
||||
In the last years APM solutions are evolving from application performance monitoring tools to more feature full systems that incorporating observability, performance data collection and analysis, which is more to date with distributed cloud-native applications.
|
||||
|
||||
Our experience with APM relates to the instrumentation of applications. This includes exposing metrics, tracing and integration with external services such as [New Relic](https://newrelic.com/). We decided to go for this approach given the simplicity and the benefits they proved on a daily basis when analyzing and optimizing our software.
|
||||
8
radar/2021-07-01/artifactory.md
Normal file
8
radar/2021-07-01/artifactory.md
Normal file
@@ -0,0 +1,8 @@
|
||||
---
|
||||
title: "Artifactory"
|
||||
ring: adopt
|
||||
quadrant: platforms-and-aoe-services
|
||||
featured: false
|
||||
---
|
||||
|
||||
Artifactory is still a valid tool but SCM platforms tools like [GitLab](https://gitlab.org/) and similar hosted services offer integrated artifact management which remove the requirements for external artifact management in many projects.
|
||||
7
radar/2021-07-01/beyondcorp.md
Normal file
7
radar/2021-07-01/beyondcorp.md
Normal file
@@ -0,0 +1,7 @@
|
||||
---
|
||||
title: "ZeroTrust"
|
||||
ring: adopt
|
||||
quadrant: methods-and-patterns
|
||||
---
|
||||
|
||||
Because this approach is more and more used and especially useful for distributed architectures, we updated this item to "adopt" and recommend using it in relevant problem areas.
|
||||
18
radar/2021-07-01/checkov.md
Normal file
18
radar/2021-07-01/checkov.md
Normal file
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: "Checkov"
|
||||
ring: assess
|
||||
quadrant: platforms-and-aoe-services
|
||||
---
|
||||
|
||||
Checkov is a static code analysis tool for infrastructure-as-code.
|
||||
|
||||
It scans cloud infrastructure provisioned using
|
||||
|
||||
- Terraform
|
||||
- Terraform plan
|
||||
- Cloudformation
|
||||
- Kubernetes
|
||||
|
||||
and detects security and compliance misconfigurations.
|
||||
|
||||
At AOE we use Checkov in CI/CD processes to get insights into our Terraform-Modules.
|
||||
8
radar/2021-07-01/cockpit.md
Normal file
8
radar/2021-07-01/cockpit.md
Normal file
@@ -0,0 +1,8 @@
|
||||
---
|
||||
title: "Cockpit"
|
||||
ring: hold
|
||||
quadrant: tools
|
||||
featured: false
|
||||
---
|
||||
|
||||
We decided to put this CMS on hold due to other - more adopted - alternatives like [Strapi](/tools/strapi.html).
|
||||
33
radar/2021-07-01/complexity-management.md
Normal file
33
radar/2021-07-01/complexity-management.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: "Complexity Management"
|
||||
ring: trial
|
||||
quadrant: methods-and-patterns
|
||||
---
|
||||
|
||||
Our world is increasingly complex - our society and the economic system is developing fast - we constantly have to deal with surprises and uncertainty. This is especially the case in IT organisations that collaboratively and cross-functional work on innovations, "digitalization strategies" or "transformation projects".
|
||||
|
||||
Something is complex, when it is not possible to relate all its elements at the same time. There is no clear cause and result relationship. Decision making processes cannot be well structured.
|
||||
|
||||
But of course that should not be used as an excuse. This realisation can motivate us to find ways to better deal with it. To come to better and new ideas together, to take good decisions and to learn from them.
|
||||
|
||||
Complexity management capabilities describe the ability to deal with complexity. The more different dimensions are used to observe and analyse a situation, the higher they are differenciated and the faster this is done - the better complexity is managed. [C2M Model](https://www.carl-auer.de/magazin/systemzeit/komplexitatsmanagement-modell-stufen-formen)
|
||||
|
||||
The complexity in IT initiatives and projects comes from the uncertainties of how a product is adopted by the users and the market, the nearly endless choices of technical ingredients, the team and organisational structures and the established collaboration and communication etc.
|
||||
|
||||
Agile methods and other best practices evolved from that challenges - and are now widely adopted - but without proper reflection and complexity management they can also lead to dysfunctional communication patterns.
|
||||
|
||||
Since we are solving problems in collaboration we also need to deal with the complexity of the communication system (social system):
|
||||
|
||||
* We are often seeing how large and historical organisations have a hard time with their transformation initiatives.
|
||||
* We are seeing teams, where over the time dysfunctional patterns have emerged.
|
||||
* We see teams where no clear communication is established and where the important conflicts are not addressed.
|
||||
* We see teams that argue one-dimensional and spend time and energy in useless debates.
|
||||
* We see organisations that are full of internal orientation and activities - while they are losing the connection to the external customers and market.
|
||||
|
||||
An understanding of how communication systems are working - and what conditions for working communication (and therefore collaboration) exist, helps to address such situations better. It also helps to understand how we can use conflicts for creativity (creating new perspectives and ideas).
|
||||
|
||||
That includes the awareness that we can always learn from each other!
|
||||
|
||||
That is the reason we see systemic perspectives with proper system theoretical background emerging in the space of organisational development. We believe that proper learning of these perspectives and the awareness of complexity management capabilities can help organisations to form functional collaboration. This learning helps to reflect systems and oneself more conscious - and that can be a healthy condition for more impact and learning. It may also help that an organisation does not blindly follow the next model, agile "hype" or consultant promises.
|
||||
|
||||
More on that topic: [Systemic Communication](https://www.carl-auer.de/magazin/systemzeit/communication-reorganization-of-undetermined)
|
||||
14
radar/2021-07-01/conventionalcommits.md
Normal file
14
radar/2021-07-01/conventionalcommits.md
Normal file
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: "Conventional Commits"
|
||||
ring: trial
|
||||
quadrant: methods-and-patterns
|
||||
---
|
||||
|
||||
The Conventional Commits specification is a lightweight convention on top of commit messages.
|
||||
It provides a small set of rules for writing commit messages and therefore creating an explicit commit history.
|
||||
The convention dovetails with [SemVer](/methods-and-patterns/semver2.html), by describing the features, fixes, and breaking changes made in commit messages.
|
||||
The specification contains only 16 items that are easy to follow. The predefined structure allows everyone in the team to get a better overview of what the commit messages relates to and what part of the code a change has to do with.
|
||||
Some benefits of using these specifications include: the ability to automatically generate changelogs, the ability to determine a semantic version bump (based on the types of commits landed) and being able to communicate the nature of changes to teammates and stakeholders.
|
||||
|
||||
We use conventional commits in the team with the help of a git template.
|
||||
The template contains a guide of elements that are required in the specification plus some information about project specific items that should also be part of a commit, such as a ticket number.
|
||||
46
radar/2021-07-01/css-in-js.md
Normal file
46
radar/2021-07-01/css-in-js.md
Normal file
@@ -0,0 +1,46 @@
|
||||
---
|
||||
title: "CSS-in-JS"
|
||||
ring: trial
|
||||
quadrant: methods-and-patterns
|
||||
---
|
||||
|
||||
CSS-in-JS is a method where JavaScript is used to style components. The first libraries which implemented this technique were [Styled-Components](https://styled-components.com/), [Emotion](https://emotion.sh/) & [JSS](https://cssinjs.org/).
|
||||
|
||||
### Example:
|
||||
|
||||
```js
|
||||
const Button = styled.button`
|
||||
display: inline-block;
|
||||
padding: 0.5rem 0;
|
||||
background: transparent;
|
||||
color: white;
|
||||
border: 2px solid white;
|
||||
|
||||
${(props) =>
|
||||
props.primary &&
|
||||
css`
|
||||
background: white;
|
||||
color: black;
|
||||
`}
|
||||
`;
|
||||
|
||||
return <Button primary>Click me</Button>;
|
||||
```
|
||||
|
||||
Advantages of CSS-in-JS
|
||||
|
||||
- Local scoping instead of global namespace
|
||||
- No classname to element mapping
|
||||
- Use the full power of JavaScript to enhance CSS (loops, variables & more)
|
||||
- Dynamic styling & theming (access to state or props)
|
||||
- TypeScript support
|
||||
|
||||
Disadvantages of CSS-in-JS
|
||||
|
||||
- Runtime cost when using dynamic styling
|
||||
- Slightly different syntax than traditional CSS (object syntax vs template literals)
|
||||
- Can add an extra layer of complexity
|
||||
|
||||
In the meantime CSS-in-JS has evolved even more. There are some libraries which leverages nearly zero-runtime costs such as [Stitches](https://stitches.dev/) or [Vanilla Extract](https://vanilla-extract.style/) while still providing an excellent developer experience with TypeScript.
|
||||
|
||||
We at AOE think that CSS-in-JS is the future of writing good, performant and maintainable CSS, therefore we already use different CSS-in-JS solutions throughout multiple applications.
|
||||
11
radar/2021-07-01/cypress.md
Normal file
11
radar/2021-07-01/cypress.md
Normal file
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "Cypress"
|
||||
ring: adopt
|
||||
quadrant: tools
|
||||
---
|
||||
|
||||
Cypress has proven itself in AOE projects.
|
||||
With its support for JavaScript and TypeScript, Cypress is a testing tool that strongly relates to front-end developers.
|
||||
It is very easy to adopt, and the test specifications are easy to implement and to maintain.
|
||||
Test execution is very fast, and the results are well documented, understandable and easy to publish, e.g. via GitLab Pages.
|
||||
It currently supports Chrome, Firefox and Electron.
|
||||
16
radar/2021-07-01/ddev.md
Normal file
16
radar/2021-07-01/ddev.md
Normal file
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: "DDEV"
|
||||
ring: adopt
|
||||
quadrant: tools
|
||||
featured: true
|
||||
---
|
||||
|
||||
[DDEV](https://www.ddev.com/ddev-local/) is an open source tool that makes it dead simple to get local PHP development environments up and running within minutes.
|
||||
It's powerful and flexible as a result of its per-project environment configurations, which can be extended, version controlled, and shared.
|
||||
In short, DDEV aims to allow development teams to use Docker in their workflow without the complexities of bespoke configuration.
|
||||
|
||||
At AOE, we use DDEV in a variety of PHP projects (large and small).
|
||||
It has made the onboarding process extremely easy for new developers and developers who have already worked with DDEV feel right at home in other projects.
|
||||
|
||||
DDEV makes adding needed dependencies super easy and so far has met every requirement we've ever had.
|
||||
This is mainly because DDEV is just a wrapper for existing tools like Docker-Compose. However, it does take away a lot of the complexity that is normally involved in configuring these tools.
|
||||
12
radar/2021-07-01/dependency-update-scan.md
Normal file
12
radar/2021-07-01/dependency-update-scan.md
Normal file
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: "Dependency Update Scan"
|
||||
ring: trial
|
||||
quadrant: methods-and-patterns
|
||||
---
|
||||
|
||||
Tools for automated dependency updates continue to offer a big productivity gain when integrated well into the build workflow.
|
||||
|
||||
Nonetheless, this comes not without a word of warning.
|
||||
While it's great in theory, constant updates might quickly lead to a bombardment of merge requests.
|
||||
It is crucial that the chosen tools work reliably and are really well integrated. Otherwise, this might become overwhelming for teams.
|
||||
As an alternative, we also had good experience with disabled automatic merge requests and just manually triggered a job when we wanted to take care of the updates.
|
||||
13
radar/2021-07-01/dgs.md
Normal file
13
radar/2021-07-01/dgs.md
Normal file
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: "DGS Framework"
|
||||
ring: assess
|
||||
quadrant: tools
|
||||
---
|
||||
|
||||
The [DGS Framework](https://netflix.github.io/dgs/) is a [GraphQL](https://graphql.org/) server framework based on [Spring Boot](https://spring.io/projects/spring-boot/).
|
||||
It extends [GraphQL Java](https://www.graphql-java.com/) with additional features such as:
|
||||
- an annotation-based programming model for Spring
|
||||
- a test framework for writing query tests as unit tests
|
||||
- a [Gradle](https://gradle.org/) code generation plugin to create types from a GraphQL schema
|
||||
|
||||
It works well with both Java and Kotlin and allowed us a quick start with getting our first GraphQL servers up and running.
|
||||
12
radar/2021-07-01/diagrams-as-code.md
Normal file
12
radar/2021-07-01/diagrams-as-code.md
Normal file
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: "Diagrams as Code"
|
||||
ring: adopt
|
||||
quadrant: methods-and-patterns
|
||||
---
|
||||
|
||||
Documenting concepts and software architecture as diagrams using code offers great benefit over heavier solutions.
|
||||
Having documentation and diagrams treated as code and checked-in into version control increases transparency, collaboration as well as productivity.
|
||||
The textual representation of diagrams is easy to write and read. Generation of graphical representations as SVG or PNG images is also easy with the associated tools.
|
||||
|
||||
We make heavy use of [PlantUML](/tools/plant-uml.html) combined with [Asciidoc](/tools/asciidoc.html) and tools like [AsciiDoctor Diagram](https://asciidoctor.org/docs/asciidoctor-diagram/) to include and inline PlantUML diagrams into documentations.
|
||||
The latter allows a variety of other diagram formats which can be easily mixed and matched.
|
||||
15
radar/2021-07-01/docker.md
Normal file
15
radar/2021-07-01/docker.md
Normal file
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: "Docker"
|
||||
ring: assess
|
||||
quadrant: platforms-and-aoe-services
|
||||
featured: false
|
||||
---
|
||||
|
||||
Docker is best known for its capability to build and run containers.
|
||||
This is how we have used the term "Docker" in the Tech Radar recently.
|
||||
But Docker is also a complete production platform, where the capability to build and run Containers is only a small fraction of its capabilities.
|
||||
At the same time numerous alternate runtimes for containers – like containerd and podman – as well as image builders – like Kaniko and Buildah – have evolved during the last years.
|
||||
Thanks to the standards established by the Open Container Initiative these tools are mostly interchangeable for the purposes of building and running containers.
|
||||
|
||||
To be more distinct, we now recommend using [Containers and Runtimes as specified by the Open Container Initiative](/platforms-and-aoe-services/oci-container.html).
|
||||
Docker is one of many tools to achieve that.
|
||||
13
radar/2021-07-01/drupal.md
Normal file
13
radar/2021-07-01/drupal.md
Normal file
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: "Drupal"
|
||||
ring: trial
|
||||
quadrant: tools
|
||||
featured: true
|
||||
---
|
||||
|
||||
[Drupal](https://www.drupal.org/) is an open source content management system and framework based on a PHP stack.
|
||||
It has a huge community, so it's no wonder it's among the top 10 CMS worldwide in terms of market share.
|
||||
|
||||
At AOE we consume Drupal mainly headless via JSON API. We appreciate its large feature set and mature plugin system as well as the general ecosystem.
|
||||
|
||||
In addition, the extensive documentation and setup with [DDEV](/tools/ddev.html) make it easy to get started.
|
||||
18
radar/2021-07-01/eks.md
Normal file
18
radar/2021-07-01/eks.md
Normal file
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: "Amazon EKS"
|
||||
ring: adopt
|
||||
quadrant: platforms-and-aoe-services
|
||||
---
|
||||
|
||||
[Amazon Elastic Kubernetes Service](https://aws.amazon.com/de/eks/) (Amazon EKS) is a managed service that makes it easy for you to run Kubernetes on AWS without needing to stand up or maintain your own Kubernetes control plane or workloads.
|
||||
Amazon EKS runs Kubernetes control plane instances across multiple Availability Zones to ensure high availability.
|
||||
It also provides automated version upgrades and patching for them.
|
||||
|
||||
Amazon EKS is fully supported by [Terraform](https://www.aoe.com/techradar/platforms-and-aoe-services/terraform.html) which brings the advantage that its configuration is written in code,
|
||||
which fulfils the [infrastructure as code](https://www.aoe.com/techradar/platforms-and-aoe-services/infrastructure-as-code.html) philosophy.
|
||||
Amazon has also implemented important (security) features to their service to ensure that Amazon EKS is well integrated into the broader AWS landscape.
|
||||
Kubernetes version upgrades and security patches are provided in a reliable schedule and with proper documentation.
|
||||
Alongside with the managed service, Amazons also provides its own [EKS distribution](https://aws.amazon.com/de/blogs/opensource/introducing-amazon-eks-distro/) which closes the gap for on-premise installations.
|
||||
|
||||
Different Amazon EKS Clusters are in use on a variety of environments like development, integration, testing and production.
|
||||
We experienced that Kubernetes version updates are done without major efforts or impact to the running cluster. Along with that, using EKS avoids a lot of low-level optimization and component management which were required in manually configured clusters in the past.
|
||||
6
radar/2021-07-01/elk-stack.md
Normal file
6
radar/2021-07-01/elk-stack.md
Normal file
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: "ELK Stack"
|
||||
ring: adopt
|
||||
quadrant: platforms-and-aoe-services
|
||||
featured: false
|
||||
---
|
||||
8
radar/2021-07-01/flowtype.md
Normal file
8
radar/2021-07-01/flowtype.md
Normal file
@@ -0,0 +1,8 @@
|
||||
---
|
||||
title: "Flow"
|
||||
ring: hold
|
||||
quadrant: tools
|
||||
featured: false
|
||||
---
|
||||
|
||||
With a much larger community, better support from frameworks (React, Angular, Vue) and IDEs and a similar feature set, Typescript is the better choice instead of Flow.
|
||||
9
radar/2021-07-01/fluentd.md
Normal file
9
radar/2021-07-01/fluentd.md
Normal file
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: "Fluentd"
|
||||
ring: assess
|
||||
quadrant: tools
|
||||
|
||||
---
|
||||
**Fluentd** is a great tool to gather logs, transform them into any required format and distribute them to any logging backend.
|
||||
|
||||
At AOE we use fluentd in different contexts, but mostly to gather logs from kubernetes clusters into data backends like Elasticsearch.
|
||||
17
radar/2021-07-01/flutter.md
Normal file
17
radar/2021-07-01/flutter.md
Normal file
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: "Flutter"
|
||||
ring: assess
|
||||
quadrant: languages-and-frameworks
|
||||
---
|
||||
|
||||
[Flutter](https://flutter.io) allows writing native applications for different platforms with a single code base in [Dart](https://dart.dev).
|
||||
|
||||
It provides stable platform implementations for both major mobile platforms iOS and Android.
|
||||
With [Flutter on the Web](https://flutter.dev/web) it is possible to build single-page applications (SPA) out of the same code with full support for service workers.
|
||||
The [Desktop](https://flutter.dev/desktop) (Windows, Mac, Linux) platform is currently still in beta (as of mid 2021).
|
||||
|
||||
The compilation into native platform code prevents from bottleneck-issues due context switching and runtime bridging, which can be found in other cross-platform frameworks like [React Native](https://reactnative.dev).
|
||||
|
||||
Comparing to a Javascript-based PWA, Flutter's approach promises a better performance and energy-efficiency.
|
||||
|
||||
We gathered first positive experience with small applications, which used the Alpha and Beta state of Flutter for Linux (x64) and Web by the time of development.
|
||||
9
radar/2021-07-01/gatling.md
Normal file
9
radar/2021-07-01/gatling.md
Normal file
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: "Gatling"
|
||||
ring: adopt
|
||||
quadrant: tools
|
||||
featured: false
|
||||
---
|
||||
|
||||
Gatling is still a valid tool which is widely used in our teams.
|
||||
Other alternatives like [Locust](https://locust.io/) exist and fill the same niche but Gatling is a better fit for our toolstack.
|
||||
12
radar/2021-07-01/graalnaative.md
Normal file
12
radar/2021-07-01/graalnaative.md
Normal file
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: "Graal Native Image"
|
||||
ring: trial
|
||||
quadrant: tools
|
||||
---
|
||||
|
||||
Native Image is a technology to ahead-of-time compile Java code to a standalone executable, called a native image.
|
||||
In the process of building a native image all library dependencies, including those from the JDK will be packed in the native image.
|
||||
The application created as a native image can be run without a JDK.
|
||||
The natively compiled applications require generally less memory and have shorter start up times.
|
||||
|
||||
We at AOE have already running microservices written in Scala with Graal Native Image.
|
||||
9
radar/2021-07-01/helm.md
Normal file
9
radar/2021-07-01/helm.md
Normal file
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: "Helm"
|
||||
ring: adopt
|
||||
quadrant: platforms-and-aoe-services
|
||||
---
|
||||
|
||||
Helm has a fast growing community and is used in more and more projects.
|
||||
It's our default tool to manage Kubernetes resources - every other alternative has to benchmark itself with it.
|
||||
Therefore, we have updated it to "adopt".
|
||||
15
radar/2021-07-01/k6.md
Normal file
15
radar/2021-07-01/k6.md
Normal file
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: "k6"
|
||||
ring: assess
|
||||
quadrant: tools
|
||||
---
|
||||
|
||||
Load Testing is a testing process in which the performance of a software application or system is tested under a specific expected load.
|
||||
It determines how the system behaves while being accessed by multiple users simultaneously.
|
||||
The goals of Load Testing is to improve performance bottlenecks and to ensure stability under high traffic.
|
||||
When done regularly, it provides confidence in the system, its reliability and performance, helps identify the bottlenecks in the system under heavy user stress scenarios before they happen in a production environment, and gives protection against poor user experience when using the system.
|
||||
|
||||
[K6](https://k6.io/) is a developer-centric, free and open-source load testing tool.
|
||||
The command line runner executes scripts written in JavaScript and allows to configure the execution time and the number of virtual users.
|
||||
The tool can be used for load testing and performance testing.
|
||||
However, it can not be used to run tests that rely only on the browser, making it more suitable for testing of APIs.
|
||||
16
radar/2021-07-01/kubernetes-operators.md
Normal file
16
radar/2021-07-01/kubernetes-operators.md
Normal file
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: "Kubernetes Operators"
|
||||
ring: trial
|
||||
quadrant: methods-and-patterns
|
||||
---
|
||||
|
||||
The [Kubernetes Operators](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) allow to manage application configuration within Kubernetes through [custom resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
|
||||
The operators are implemented as Kubernetes controllers and all interaction happens through the Kubernetes API.
|
||||
This allows to manage application deployment and configuration with the same toolset, it also allows to create another abstraction layer to describe the desired application state and let the operator decide how this state should be reached.
|
||||
|
||||
Kubernetes Operators are widely available for many community projects.
|
||||
These can be shared and found on [operatorhub.io](https://operatorhub.io/).
|
||||
Implementing custom operators is greatly simplified through the [Operators SDK](https://sdk.operatorframework.io/) which is used as base for many [existing implementations](https://github.com/operator-framework/awesome-operators).
|
||||
|
||||
We use operators in most projects and prefer them to custom management code.
|
||||
We encourage teams to try the existing community operators for e.g. observability and operations tasks.
|
||||
14
radar/2021-07-01/loki.md
Normal file
14
radar/2021-07-01/loki.md
Normal file
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: "Loki"
|
||||
ring: trial
|
||||
quadrant: tools
|
||||
featured: true
|
||||
---
|
||||
|
||||
Archiving indexed log data with a system like Elasticsearch can be expensive and archiving it as simple text files makes it hard to query them.
|
||||
[Loki](https://grafana.com/oss/loki/) solves this issue by adding a reference database based on Kubernetes labels to each log line similar to Prometheus, but holding the log data inside a simple blob storage like S3.
|
||||
This allows the user to query the data by pre-defined labels and keeps the costs for indexing low.
|
||||
|
||||
Another benefit is the fact that does not have an endpoint for mutating log data which makes the data immutable from a potential compromised system.
|
||||
|
||||
We at AOE are using it for longer term log archiving in several Kubernetes clusters.
|
||||
10
radar/2021-07-01/micro-frontends.md
Normal file
10
radar/2021-07-01/micro-frontends.md
Normal file
@@ -0,0 +1,10 @@
|
||||
---
|
||||
title: "Micro Frontends"
|
||||
ring: adopt
|
||||
quadrant: methods-and-patterns
|
||||
---
|
||||
|
||||
The Micro Frontends approach continues to prove to be a valuable pattern for large-scale systems developed by several teams.
|
||||
Therefore, we moved this pattern to "adopt".
|
||||
|
||||
We use [page composing](methods-and-patterns/page-composing.html) as one implementation of this pattern.
|
||||
14
radar/2021-07-01/mlops.md
Normal file
14
radar/2021-07-01/mlops.md
Normal file
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: "MLOps"
|
||||
ring: assess
|
||||
quadrant: methods-and-patterns
|
||||
---
|
||||
|
||||
After spending some time diving into the world of data science and machine learning we're realizing our existing DevOps best practices aren't a perfect fit for the specific workflows we're seeing here.
|
||||
Data science is not only about code but also all about managing large datasets and models.
|
||||
Data is being analyzed, models are being trained in many iterations and then software needs to be deployed that does the actual prediction/inference.
|
||||
And this circle (see: CRISP-DM) will repeat over and over again during the development phase and after the first production release.
|
||||
"**MLOps**" extends the DevOps best practices in order to cover these new scenarios specific to machine learning workflows.
|
||||
|
||||
[DVC](https://dvc.org/) helps dealing with large data sets and models by connecting external storage to your Git repositories and [CML](https://cml.dev/) helps integrating the CI/CD into your GitHub or GitLab workflows.
|
||||
Since we're already using Kubernetes extensively we're exploring [Kubeflow](https://www.kubeflow.org/) for running the full machine learning workflow on Kubernetes clusters.
|
||||
12
radar/2021-07-01/nats.md
Normal file
12
radar/2021-07-01/nats.md
Normal file
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: "NATS"
|
||||
ring: assess
|
||||
quadrant: tools
|
||||
featured: true
|
||||
---
|
||||
|
||||
[NATS](https://nats.io/) is a cloud native messaging and stream-data system for modern distributed software systems.
|
||||
Two [design-goals](https://github.com/nats-io/nats-general/blob/master/architecture/DESIGN.md) were simplicity and performance.
|
||||
These are adopted by selecting [golang](https://golang.org/) for the server implementation and reducing the memory footprint for both: server- and client-side.
|
||||
The server-side provides simple and efficient horizontal scaling (e.g. deploying it inside Kubernetes) and the small client-footprint allows us to use it in embedded-systems, edge-computing and IoT devices e.g. for command and controll use-cases.
|
||||
Also, the long list of existing [integrations](https://docs.nats.io/compare-nats#integrations) and the plugin-systems bring a great flexibility.
|
||||
11
radar/2021-07-01/next-js.md
Normal file
11
radar/2021-07-01/next-js.md
Normal file
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "Next.js"
|
||||
ring: adopt
|
||||
quadrant: languages-and-frameworks
|
||||
---
|
||||
|
||||
[Next.js](https://nextjs.org/) claims itself as **the** React framework for production.
|
||||
It comes with first-class developer experience and many features for example: hybrid static & server-side rendering, TypeScript support, image optimization, code splitting & much more.
|
||||
|
||||
We at AOE are already using Next.js for some big projects.
|
||||
The main reason for that is the modern stack (React with TypeScript) and the possibility to render on the server (static pre-rendering or dynamic SSR) to be able to get crawled by search engines and stay SEO relevant.
|
||||
6
radar/2021-07-01/node-js.md
Normal file
6
radar/2021-07-01/node-js.md
Normal file
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: "node.js"
|
||||
ring: adopt
|
||||
quadrant: languages-and-frameworks
|
||||
featured: false
|
||||
---
|
||||
16
radar/2021-07-01/nx.md
Normal file
16
radar/2021-07-01/nx.md
Normal file
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: "NX"
|
||||
ring: assess
|
||||
quadrant: tools
|
||||
featured: true
|
||||
---
|
||||
|
||||
[Nx](https://nx.dev/) is a suite of powerful, extensible dev tools to help you architect, test, and build at any scale.
|
||||
It is mainly applicable in the environment of React, Angular and Node.js and tries to simplify and streamline the work in a mono repo.
|
||||
|
||||
At AOE, we are currently taking our first steps with NX in a mono repo that is home to both our React and Next.js based frontend and our [Go](/languages-and-frameworks/go-lang.html) / [Flamingo](/languages-and-frameworks/flamingo.html) based backend.
|
||||
|
||||
The integration with the Node.js components (React, Next.js, Cypress) works smoothly and brings the expected benefits such as faster build times through intelligent caching.
|
||||
Support for Go is currently only rudimentary, which is why NX still has to prove itself in this area.
|
||||
|
||||
Especially in the environment of Node.js in combination with the use of a mono repo, NX is worth a look.
|
||||
17
radar/2021-07-01/oci-container.md
Normal file
17
radar/2021-07-01/oci-container.md
Normal file
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: "OCI Container"
|
||||
ring: adopt
|
||||
quadrant: platforms-and-aoe-services
|
||||
---
|
||||
|
||||
OCI-compatible containers are currently the most-used solution for creating and managing container-based infrastructures and deployments.
|
||||
|
||||
Containers and their runtime are an easy way to run applications and services as an isolated process (using Linux kernel cgroups, network namespaces and custom mounts).
|
||||
|
||||
In a DevOps environment, this helps a lot as we can run the exact same software and runtime (such as NodeJS) on both production and locally while developing. This enables us to debug our software much easier. We can compose our project development setup out of small containers. Also, containers allow us to keep our development environment much simpler and independent of our developer's operating system or pre-installed software versions.
|
||||
|
||||
In a CI environment building the containers allows us to package and test the whole environment instead of different software components on different runtimes in a much more stable way.
|
||||
|
||||
Backed by services such as [Kubernetes](/platforms-and-aoe-services/kubernetes.html) and [Helm](/platforms-and-aoe-services/helm.html), we can deploy containers on a flexible infrastructure and enable our developers to test their software more easily in different environments.
|
||||
|
||||
Here at AOE, we use containers in different projects to become more flexible and faster, which increases our focus on development of even better and more stable software.
|
||||
18
radar/2021-07-01/open-policy-agent.md
Normal file
18
radar/2021-07-01/open-policy-agent.md
Normal file
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: "Open Policy Agent"
|
||||
ring: assess
|
||||
quadrant: tools
|
||||
---
|
||||
|
||||
[Open Policy Agent](https://www.openpolicyagent.org/) (OPA) is a framework which allows modelling and evaluating policy access services.
|
||||
The underlying expression language *Rego* is purpose-built for the policy evaluations and implements the **Policy As Code** pattern.
|
||||
|
||||
This allows to decouple policy from the service's code, so you can release, and review policies separately.
|
||||
|
||||
The benefits of using OPA and Rego comes from the various available integrations into other cloud-native services and tools.
|
||||
It can be used with the "Kubernetes Admission Controller", to authorize decisions within a Service Mesh or as part of infrastructure evaluation pipelines.
|
||||
|
||||
We use OPA in some of our infrastructure pipelines to ensure that changes don't have undesired impact or within Kubernetes to evaluate the overall conformity of our deployments with the given policies.
|
||||
|
||||
We have also evaluated OPA as part of permission management in distributed architectures.
|
||||
The concept promises to provide value especially for distributed enterprise architectures.
|
||||
9
radar/2021-07-01/pact.md
Normal file
9
radar/2021-07-01/pact.md
Normal file
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: "PACT"
|
||||
ring: trial
|
||||
quadrant: tools
|
||||
featured: false
|
||||
---
|
||||
|
||||
At AOE we continue to use PACT but would like to use it even more.
|
||||
It therefore remains in the trial ring but was faded out from the overview page.
|
||||
16
radar/2021-07-01/page-composing.md
Normal file
16
radar/2021-07-01/page-composing.md
Normal file
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: "Page Composing"
|
||||
ring: trial
|
||||
quadrant: methods-and-patterns
|
||||
---
|
||||
|
||||
Page composing is a way to aggregate multiple independent page fragments into one combined web page.
|
||||
As an implementation of [Micro Frontends](methods-and-patterns/micro-frontends.html), this approach supports to deploy and run services agnostic to the technologies used per team.
|
||||
|
||||
The concept builds upon the fact that all involved services deliver valid HTML as their output.
|
||||
Our solution is a small application which takes care of gathering the page fragments from all services and composing each into a defined HTML template.
|
||||
A configuration layer further allows controlling which fragment gets pulled from the serving instance.
|
||||
|
||||
With such a page composing application in place, teams can autonomously develop, deploy and operate their service with the freedom of choosing technologies and release strategies.
|
||||
|
||||
Martin Fowler et al. described this as [Server-side template composition](https://martinfowler.com/articles/micro-frontends.html#Server-sideTemplateComposition).
|
||||
6
radar/2021-07-01/pin-external-dependencies.md
Normal file
6
radar/2021-07-01/pin-external-dependencies.md
Normal file
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: "Pin external dependencies"
|
||||
ring: adopt
|
||||
quadrant: methods-and-patterns
|
||||
featured: false
|
||||
---
|
||||
6
radar/2021-07-01/plant-uml.md
Normal file
6
radar/2021-07-01/plant-uml.md
Normal file
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: "Plant UML"
|
||||
ring: adopt
|
||||
quadrant: tools
|
||||
featured: false
|
||||
---
|
||||
9
radar/2021-07-01/postman.md
Normal file
9
radar/2021-07-01/postman.md
Normal file
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: "Postman"
|
||||
ring: adopt
|
||||
quadrant: tools
|
||||
featured: false
|
||||
---
|
||||
|
||||
Postman is now the tool of choice for API testing and widely used in our projects.
|
||||
We therefore moved it to the **Adopt** level.
|
||||
18
radar/2021-07-01/prometheus.md
Normal file
18
radar/2021-07-01/prometheus.md
Normal file
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: "Prometheus"
|
||||
ring: adopt
|
||||
quadrant: platforms-and-aoe-services
|
||||
---
|
||||
|
||||
[Prometheus](https://prometheus.io) is an open-source monitoring and alerting system.
|
||||
It was the second project within the CNCF which reached the "graduated" status and has since seen a large rate of adoption across many CNCF projects.
|
||||
It primarily utilizes a pull-based metrics flow through HTTP which allows the easy integration of a variety of application-specific metrics sources.
|
||||
Compared to other monitoring systems it stands out in its simple, still powerful and fully code-based configuration and the equally powerful service discovery mechanism.
|
||||
|
||||
Prometheus integrates very well with Grafana which is our tool of choice for dashboard visualization.
|
||||
Through the [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator) project, the monitoring system can be configured through Kubernetes custom resource definitions.
|
||||
These can be shipped by development teams alongside with their application deployments and allow [sharing responsibility](https://www.aoe.com/techradar/methods-and-patterns/shared-responsibility.html) for monitoring tasks between operations and engineering teams with a clear interface.
|
||||
|
||||
With [Cortex](https://cortexmetrics.io/) and [Thanos](https://thanos.io/) the Prometheus-ecosystem knows two well-settled solutions for high-availability of the underlying time series database and with [Amazon Managed Services for Prometheus](https://aws.amazon.com/en/prometheus/) there's also a SaaS-Solution available.
|
||||
|
||||
We use Prometheus in nearly every project, it's an essential part of our underlying operations and also well understood by many development teams.
|
||||
6
radar/2021-07-01/protobuf.md
Normal file
6
radar/2021-07-01/protobuf.md
Normal file
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: "Protobuf"
|
||||
ring: adopt
|
||||
quadrant: languages-and-frameworks
|
||||
featured: false
|
||||
---
|
||||
21
radar/2021-07-01/pulumi.md
Normal file
21
radar/2021-07-01/pulumi.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "Pulumi"
|
||||
ring: assess
|
||||
quadrant: platforms-and-aoe-services
|
||||
---
|
||||
|
||||
[Pulumi](https://www.pulumi.com/) is a tool in the infrastructure-as-code space that is quite similar to [Terraform](https://www.terraform.io/) in that it also provide a declarative way to provision cloud infrastructure and services.
|
||||
|
||||
What makes it interesting is that all configuration is done in one of currently 4 supported general-purpose languages/runtimes:
|
||||
* Javascript/Typescript
|
||||
* Python
|
||||
* .NET Core
|
||||
* Go
|
||||
|
||||
This differs from the Terraform approach which is using its own domain specific 'Terraform Configuration Language'.
|
||||
While Terraform kept this language intentionally small and limited in functionality in order to make it purely declarative sometimes there is the need to abstract over configuration to keep your configs "DRY".
|
||||
For this there are modules in Terraform but sometimes all you need is a small function to iterate an input.
|
||||
|
||||
This is where Pulumi shines by allowing you to use the powers of the chosen programming language to build whatever abstractions you need to get the job done.
|
||||
|
||||
We currently test-drive it in small projects to compare it over Terraform.
|
||||
17
radar/2021-07-01/python-for-infrastructure.md
Normal file
17
radar/2021-07-01/python-for-infrastructure.md
Normal file
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: "Python for Infrastructure Glue Code"
|
||||
ring: assess
|
||||
quadrant: platforms-and-aoe-services
|
||||
---
|
||||
|
||||
[Python](https://www.python.org) is an easy to learn programming language that is pre-installed on most Linux distributions and CI runners.
|
||||
This makes it an ideal candidate for infrastructure glue code and adapters.
|
||||
|
||||
Shell scripts serve the same purpose.
|
||||
But they usually start simple and get more complex over time.
|
||||
This is the point where Python's features like testing capabilities, modularity, variable scoping and refactoring support comes in strong.
|
||||
We found that Python scripts are easier maintained in the long run and pose a lower barrier for contributions by our development teams.
|
||||
And they run across platforms and shells without much trouble which is a big plus for developers running different operating systems.
|
||||
|
||||
The Python language has a wide eco-system and a vast module library that can simplify scripting significantly.
|
||||
We currently value [requests](https://pypi.org/project/requests/) for HTTP API calls and [Click](https://click.palletsprojects.com/en/7.x/) for simple interactive CLI scripts, along with [pytest](https://docs.pytest.org/) for automated testing.
|
||||
6
radar/2021-07-01/redux.md
Normal file
6
radar/2021-07-01/redux.md
Normal file
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: "Redux"
|
||||
ring: trial
|
||||
quadrant: languages-and-frameworks
|
||||
featured: false
|
||||
---
|
||||
15
radar/2021-07-01/renovate.md
Normal file
15
radar/2021-07-01/renovate.md
Normal file
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: "Renovate"
|
||||
ring: trial
|
||||
quadrant: tools
|
||||
---
|
||||
|
||||
[Renovate](https://github.com/renovatebot/renovate/) is an automated dependency update tool.
|
||||
It vastly reduces the time and effort spent on keeping a project's dependencies up-to-date by automatically creating merge requests whenever a dependency needs to be updated.
|
||||
The tool is easy to set up and configure, offers built-in support for monorepo architectures and works with various programming languages and package managers, e.g.
|
||||
|
||||
- JavaScript & Yarn
|
||||
- Java & Gradle
|
||||
- PHP & Composer
|
||||
|
||||
At AOE, we use the [Renovate CLI tool](https://www.npmjs.com/package/renovate/) in the CI pipelines of a constantly growing number of projects.
|
||||
19
radar/2021-07-01/rust.md
Normal file
19
radar/2021-07-01/rust.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: "Rust"
|
||||
ring: "assess"
|
||||
quadrant: "languages-and-frameworks"
|
||||
featured: true
|
||||
---
|
||||
|
||||
[Rust](https://www.rust-lang.org/) is a young and modern programming language initially developed by [Mozilla Research](https://research.mozilla.org/).
|
||||
|
||||
It provides a strict type system, compile-time memory-safety, excellent [package manager](https://doc.rust-lang.org/cargo/), object-oriented & functional programming, task-based concurrency, good readability and maintainability and many more.
|
||||
It has a C/C++ [comparable efficiency](https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf) and helps the programmer to avoid unnecessary security-relevant memory-related bugs during compile-time.
|
||||
Since every memory-allocation is directly released after it can't be used anymore ([owner deletion](https://medium.com/@rabin_gaire/memory-management-rust-cf65c8465570)), no garbage collection is needed.
|
||||
|
||||
C/C++ code/libraries can be integrated by its [binding generator tool](https://github.com/rust-lang/rust-bindgen).
|
||||
|
||||
At stackoverflow it is votes 5 years in a row ([2016](https://insights.stackoverflow.com/survey/2016#technology-most-loved-dreaded-and-wanted), [2017](https://insights.stackoverflow.com/survey/2017#technology-_-most-loved-dreaded-and-wanted-languages), [2018](https://insights.stackoverflow.com/survey/2018#technology-_-most-loved-dreaded-and-wanted-languages), [2019](https://insights.stackoverflow.com/survey/2019#technology-_-most-loved-dreaded-and-wanted-languages), [2020](https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-languages-loved)) for the `most loved programming-language` by programmers.
|
||||
The [popularity](https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-languages-loved) is growing continuous.
|
||||
|
||||
With it's memory-safety/efficiency and energy-efficiency it helps to save money for bug-fixing, energy and cloud-computing.
|
||||
14
radar/2021-07-01/rxjs.md
Normal file
14
radar/2021-07-01/rxjs.md
Normal file
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: "RxJs"
|
||||
ring: adopt
|
||||
quadrant: languages-and-frameworks
|
||||
|
||||
---
|
||||
RX/JS aka reactive streams
|
||||
|
||||
RxJS is an implementation for the reactive programming paradigm which implements mostly the observer and iterator pattern and follows the functional programming ideas.
|
||||
The pattern actually got a renaissance because it's not completely new but has new implementations in many frameworks and languages like Angular, Akka, Spring and many more.
|
||||
Reason for that attention actually is (in the JavaScript world), that observables can be cancelled (by rules too) and observables can pass (stream) data on multiple events.
|
||||
Both aspects are not well realizable using promises e.g. and both were also detected as a huge limitation in the JavaScript community — and so it's worth to get an understanding for reactive programming in general.
|
||||
|
||||
We at AOE actually use RxJS in combination with Angular and can fully recommend the approach of observables.
|
||||
33
radar/2021-07-01/scala3.md
Normal file
33
radar/2021-07-01/scala3.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: "Scala 3"
|
||||
ring: "trial"
|
||||
quadrant: "languages-and-frameworks"
|
||||
featured: true
|
||||
---
|
||||
|
||||
[Scala 3](https://docs.scala-lang.org/scala3/) is the successor of the Scala 2.x series programming language.
|
||||
|
||||
It's not just a small iteration on Scala 2 but a complete overhaul of the language trying to improve in several areas like:
|
||||
* Syntax
|
||||
* "quiet" syntax for control structures like `if`, `while` and `for`
|
||||
* optional `new` operator
|
||||
* Optional braces with significant-indentation syntax like in python
|
||||
* Completely revised `implicit`s - see below
|
||||
* Contextual Abstractions focusing on intent instead of mechanics
|
||||
* Abstracting over contextual information with `using`
|
||||
* Providing type-class instances via `given`
|
||||
* direct extension method syntax `extension (s: String) def pirate: String = s"$s arr!"`
|
||||
* Type System improvements
|
||||
* `enum`s
|
||||
* opaque types
|
||||
* intersection and union types
|
||||
* dependent function types
|
||||
* polymorphic function types
|
||||
* type lambdas
|
||||
* match types
|
||||
* Improvements for object oriented design
|
||||
* Completely new metaprogramming facilities while Scala 2 macros were removed
|
||||
|
||||
Even with these big changes Scala 3 provides a great compatibility story supporting Scala >2.13.5 libraries in Scala 3 projects and vice versa.
|
||||
|
||||
Although slowly we will update our existing Scala 2 codebase to Scala 3 over the next months and years to take advantage of the improvements made.
|
||||
12
radar/2021-07-01/semver2.md
Normal file
12
radar/2021-07-01/semver2.md
Normal file
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: "Semantic Versioning 2.0"
|
||||
ring: adopt
|
||||
quadrant: methods-and-patterns
|
||||
featured: false
|
||||
---
|
||||
|
||||
[Semantic Versioning 2.0](https://semver.org/spec/v2.0.0.html) is a scheme for specifying a software's version.
|
||||
As the de facto standard, this is widely used and established in all areas of software development.
|
||||
It offers a clear way of communicating changes over the lifetime of the software being developed.
|
||||
|
||||
Especially in large-scale projects with many components being dependent on each other, it is important to use unambiguous communication across teams.
|
||||
20
radar/2021-07-01/service-mesh.md
Normal file
20
radar/2021-07-01/service-mesh.md
Normal file
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: "Service Mesh"
|
||||
ring: assess
|
||||
quadrant: platforms-and-aoe-services
|
||||
|
||||
---
|
||||
**Service Mesh** is a solution which makes service to service communication more comfortable and more secure in large microservice architectures.
|
||||
It decouples the routing part from the microservices which allows a service mesh implementation to offer features like:
|
||||
- Service Discovery (canary routing, a-b testing, etc.)
|
||||
- Resilience (circuit breaking, timeouts, etc.)
|
||||
- Observability (route metrics, traffic logging, etc.)
|
||||
- End-to-end encryption (mTLS)
|
||||
|
||||
service mesh implementations:
|
||||
- [Istio](https://istio.io/)
|
||||
- [Open Service Mesh](https://openservicemesh.io/)
|
||||
- [Kuma](https://kuma.io/)
|
||||
- and many more...
|
||||
|
||||
At AOE we are using service meshes in multiple projects and are assessing best-practices and service mesh implementations.
|
||||
6
radar/2021-07-01/settings-injection.md
Normal file
6
radar/2021-07-01/settings-injection.md
Normal file
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: "Settings Injection"
|
||||
ring: adopt
|
||||
quadrant: methods-and-patterns
|
||||
featured: false
|
||||
---
|
||||
9
radar/2021-07-01/shared-responsibility.md
Normal file
9
radar/2021-07-01/shared-responsibility.md
Normal file
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: "Shared Responsibility Model"
|
||||
ring: trial
|
||||
quadrant: methods-and-patterns
|
||||
---
|
||||
|
||||
Since introducing "Platform Engineering Team" who build, maintain and operate our Kubernetes clusters and other related platform services, the question occurs who is in charge of the various tasks like keeping things up and running, applying critical security fixes, update software in general, keeping an eye on the bill and many more topics.
|
||||
We're not proposing a solution on how to split responsibilities here, but we want to raise awareness for bringing everybody together and formally discuss all responsibilities and write them down similar to (and possibly extending) AWS's [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/).
|
||||
Some topics are 24/7 on-call support, broken deployment pipelines, and vulnerability scans.
|
||||
14
radar/2021-07-01/sitespeed.md
Normal file
14
radar/2021-07-01/sitespeed.md
Normal file
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: "Sitespeed.io"
|
||||
ring: assess
|
||||
quadrant: tools
|
||||
---
|
||||
|
||||
Web Performance Monitoring is the process of measuring a Web service’s ability to respond efficiently to user interactions.
|
||||
Data gathered through monitoring helps analyze performance bottlenecks, plan improvements, and measure a site's responsiveness.
|
||||
|
||||
[Sitespeed.io](https://www.sitespeed.io/) is a set of Open Source tools that makes it easy to monitor and measure the performance of a website.
|
||||
It tests websites using real (or headless) browsers, simulating users connectivity and collecting important user-centric metrics.
|
||||
The tools are packaged as a docker image that can be easily deployed.
|
||||
Data collected can be saved to different locations for later analysis which makes it easy to track changes.
|
||||
Last, Sitespeed.io can be used as part of a continuous integration pipeline or as part of a monitoring solution.
|
||||
15
radar/2021-07-01/state-management-pattern.md
Normal file
15
radar/2021-07-01/state-management-pattern.md
Normal file
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: "State Management Pattern"
|
||||
ring: adopt
|
||||
quadrant: methods-and-patterns
|
||||
---
|
||||
|
||||
State Management is a design pattern with the goal of properly sharing state data across components and separating domain representation from state management.
|
||||
This pattern is applied by many popular web frameworks such as [Vuex](/languages-and-frameworks/vuex.html), [Redux](/languages-and-frameworks/redux.html) or [Flux](/methods-and-patterns/flux.html).
|
||||
|
||||
Especially in [reactive](/methods-and-patterns/reactive-programming.html) systems, this pattern helps to solve the task of maintaining decoupled, stateless components with immutable data.
|
||||
The ways of implementing state management differs and depends on the specific requirements of the application at hand.
|
||||
|
||||
For distributed backend systems one might want to utilize [Akka's](/languages-and-frameworks/akka.html) cluster sharding module to elastically manage domain object states.
|
||||
|
||||
We use the various state management patterns across most [Vue](/languages-and-frameworks/vue.html) and [React](/languages-and-frameworks/react.html) projects that warrant them.
|
||||
15
radar/2021-07-01/storybook.md
Normal file
15
radar/2021-07-01/storybook.md
Normal file
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: "Storybook"
|
||||
ring: adopt
|
||||
quadrant: tools
|
||||
---
|
||||
|
||||
In recent years, Storybook has become the de facto standard for creating UI components in isolation.
|
||||
We have been using Storybook in many projects for quite some time now and really loving the approach.
|
||||
|
||||
With version 6, the config has been greatly simplified to achieve the goal of a zero-config approach in the future.
|
||||
* compatible and easy to integrate with major frameworks like React, Angular, Vue.js ...
|
||||
* presets for Create React App, Next.js, nuxt ...
|
||||
* build in TypeScript support
|
||||
* build in addons like controls, actions, docs ...
|
||||
* growing library of third party addons
|
||||
16
radar/2021-07-01/strapi.md
Normal file
16
radar/2021-07-01/strapi.md
Normal file
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: "Strapi"
|
||||
ring: trial
|
||||
quadrant: tools
|
||||
---
|
||||
|
||||
Strapi is a headless CMS built with Javascript on Node.js.
|
||||
Its data-centered approach offers great flexibility for many use cases by integrating with the available APIs.
|
||||
|
||||
Strapi's API comes in a RESTful and [GraphQL](/methods-and-patterns/graphql.html) variant.
|
||||
Both perfectly support the [API-first design approach](/methods-and-patterns/api-first-design-approach.html).
|
||||
|
||||
Ever since the stable release version 3.0.0 from mid-2020, the CMS reached market maturity and offers a good choice for scalable headless CMSs.
|
||||
As of the 3.6 release in April 2021, Strapi features [full internationalization support](https://strapi.io/blog/announcing-content-internationalization-v3-6), making it a viable candidate to be evaluated toe to toe with solutions like Drupal.
|
||||
|
||||
At AOE we are evaluating Strapi for various projects, appreciating its straightforward installation, setup, and use by editors in lieu of more heavy-weight solutions used in the past.
|
||||
22
radar/2021-07-01/tailwindcss.md
Normal file
22
radar/2021-07-01/tailwindcss.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "Tailwind CSS"
|
||||
ring: trial
|
||||
quadrant: languages-and-frameworks
|
||||
---
|
||||
|
||||
Tailwind CSS is a framework that heavily utilizes CSS classes.
|
||||
What seems to be a very different approach in the beginning, turns into a big "ah-ha-moment" during development and even more during the build step.
|
||||
CSS classes are entirely generated based on a configuration file that outlines the entire design system including states, nuances, etc.
|
||||
Tailwind's high flexibility results in a set of CSS classes aligned with UX/design, requiring just a fraction of code compared to a self-built solution.
|
||||
Colours, sizes, spaces etc. can have meaningful names that are easy to remember and shared between developers and designers.
|
||||
In turn, this results in a shared language with less explanation required.
|
||||
Support for deep integration into the development and build processes ensure optimized build times with incremental rebuilds only on parts really necessary.
|
||||
This obviously leads to very small build sizes with nearly 100% CSS coverage.
|
||||
|
||||
The deep integration and the extraordinary small build sizes were the main aspects for us to choose Tailwind CSS for resource-limited projects in the field of industry 4.0.
|
||||
These projects have a huge demand on a variety of interaction forms.
|
||||
|
||||
Tailwind helps us to fulfil modern user expectations by reducing the complexity of sophisticated industrial processes with a multi-device approach.
|
||||
|
||||
This is an unspoken expectation of today's operators of industrial processes.
|
||||
The evolution from classic cellular phones towards smartphones showed, there is still a huge untapped potential for usability improvements and adaptive processes, that reduce complexity especially the industry 4.0 field.
|
||||
20
radar/2021-07-01/team-start-page.md
Normal file
20
radar/2021-07-01/team-start-page.md
Normal file
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: "Team Start Page"
|
||||
ring: adopt
|
||||
quadrant: methods-and-patterns
|
||||
---
|
||||
|
||||
A team start page helps (new) members to orientate themselves.
|
||||
It normally displays all team members with their roles and contact data as well as a collection of links to the necessary tools, e.g.
|
||||
|
||||
* Project environments (staging, prod, ...)
|
||||
* Project development setup
|
||||
* Version control system
|
||||
* Code Review Tool
|
||||
* Team rules
|
||||
* Slack invitation
|
||||
* ...
|
||||
|
||||
Simply things, everyone should know.
|
||||
|
||||
At AOE we care to have a team start page for each team in our wiki.
|
||||
7
radar/2021-07-01/vue.md
Normal file
7
radar/2021-07-01/vue.md
Normal file
@@ -0,0 +1,7 @@
|
||||
---
|
||||
title: "Vue.js"
|
||||
ring: adopt
|
||||
quadrant: languages-and-frameworks
|
||||
---
|
||||
|
||||
Updated to "adopt".
|
||||
6
radar/2021-07-01/vuex.md
Normal file
6
radar/2021-07-01/vuex.md
Normal file
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: "Vuex"
|
||||
ring: assess
|
||||
quadrant: languages-and-frameworks
|
||||
featured: false
|
||||
---
|
||||
8
radar/2021-07-01/wiremock.md
Normal file
8
radar/2021-07-01/wiremock.md
Normal file
@@ -0,0 +1,8 @@
|
||||
---
|
||||
title: "WireMock"
|
||||
ring: adopt
|
||||
quadrant: tools
|
||||
featured: false
|
||||
---
|
||||
|
||||
Updated to "adopt".
|
||||
Reference in New Issue
Block a user