docs: tag blips with related academy trainings
This commit is contained in:
committed by
Stefan Rotsch
parent
e5738950cf
commit
291dfd138b
@@ -2,16 +2,17 @@
|
||||
title: "Go / Golang"
|
||||
ring: assess
|
||||
quadrant: languages-and-frameworks
|
||||
tags: [academy training, coding]
|
||||
---
|
||||
|
||||
2016 was the year of Go, with a lot of Open Source projects gaining a lot of attention and many companies started to use it.
|
||||
2016 was the year of Go, with many open-source projects gaining significant attention, and numerous companies started to adopt it.
|
||||
|
||||
Go went from #54 to #13 on the [TIOBE index](http://www.tiobe.com/tiobe-index/) in January 2017, and it became the TIOBE programming language of the year 2016.
|
||||
Go jumped from #54 to #13 on the [TIOBE index](http://www.tiobe.com/tiobe-index/) in January 2017, earning the title of TIOBE programming language of the year 2016.
|
||||
|
||||
Here at AOE, we use several services written in Go on a daily basis, such as Mattermost, Docker, Consul and Kubernetes. Also, more and more applications, such as GitLab, incorporate Go-based services to "off load" heavy work.
|
||||
Here at AOE, we rely on several services written in Go on a daily basis, such as Mattermost, Docker, Consul, and Kubernetes. Moreover, more and more applications, like GitLab, are incorporating Go-based services to handle heavy workloads.
|
||||
|
||||
Go, as a programming language, has some very interesting features such as native support for concurrency (go routines), static compiled binaries with a very small memory footprint, cross compiling and much more. A big advantage of Go is the very flat learning curve, which allows developers from more dynamic languages such as PHP to be proficient in a very short time.
|
||||
Go, as a programming language, offers several compelling features, including native support for concurrency (goroutines), statically compiled binaries with a minimal memory footprint, cross-compiling, and more. One significant advantage of Go is its shallow learning curve, enabling developers from more dynamic languages such as PHP to become proficient in a short time.
|
||||
|
||||
If you want to get a feeling for Go, you should start with the [online tour](https://tour.golang.org/welcome/1), within a day you'll have a good understanding of the core concepts, syntax, etc. - that is also because the language often tries to provide only one simple way of doing things; an example for this is that code formatting and styling is defined (yet not enforced as in Python). Part of this is also that Go itself is very opinionated: So, for example, for object oriented programming in Go, composition is the preferred way of defining data structures, and some might miss advanced concepts such as inheritance.
|
||||
If you're interested in getting a feel for Go, you should start with the [online tour](https://tour.golang.org/welcome/1). Within a day, you'll gain a good understanding of the core concepts, syntax, etc. This is partly because the language often provides only one simple way of doing things; an example of this is the defined code formatting and styling (though not enforced as in Python). Additionally, Go itself is very opinionated; for instance, composition is the preferred way of defining data structures for object-oriented programming in Go, and some developers may miss advanced concepts such as inheritance.
|
||||
|
||||
We currently use Go for projects and microservices where we need flexibility and performance.
|
||||
Currently, we use Go for projects and microservices where we require flexibility and performance.
|
||||
|
||||
@@ -2,8 +2,9 @@
|
||||
title: "Kubernetes"
|
||||
ring: assess
|
||||
quadrant: platforms-and-aoe-services
|
||||
tags: [academy training, devops]
|
||||
---
|
||||
|
||||
Kubernetes is a container orchestration platform, which supports many infrastructure providers. It allows you to deploy containers and takes care of running, scaling or self-healing your applications based on configurations you provide. It's based on years of knowledge and experience Google gained by using containers.
|
||||
Kubernetes is a container orchestration platform that supports many infrastructure providers. It enables you to deploy containers and manages the running, scaling, or self-healing of your applications based on configurations you provide. It is built on years of knowledge and experience gained by Google through its use of containers.
|
||||
|
||||
At AOE, we started Kubernetes in a test environment on bare metal to experiment with it. It's currently used for running AOE internal apps such as dashboards as well as running builds in containers. We also started to use it for upcoming projects to run and manage several services. There are Tools to automate the setup of kubernetes in AWS like [Cops](https://kubernetes.io/docs/getting-started-guides/kops/). Another helpful tool is [Minikube](https://github.com/kubernetes/minikube), which allows to test and run kubernetes locally.
|
||||
At AOE, we initially implemented Kubernetes in a test environment on bare metal to experiment with its capabilities. Currently, it is utilized for running internal AOE applications such as dashboards and for running builds in containers. We have also begun using it for upcoming projects to manage several services. There are tools available to automate the setup of Kubernetes in AWS, such as [Cops](https://kubernetes.io/docs/getting-started-guides/kops/). Another helpful tool is [Minikube](https://github.com/kubernetes/minikube), which allows for testing and running Kubernetes locally.
|
||||
|
||||
@@ -2,17 +2,16 @@
|
||||
title: "Strategic Domain Driven Design"
|
||||
ring: adopt
|
||||
quadrant: methods-and-patterns
|
||||
tags: [architecture]
|
||||
tags: [academy training, architecture]
|
||||
---
|
||||
|
||||
Design of distributed applications need to be done wisely. Strategic Domain Driven Design is an approach for modelling large-scale applications and systems and is introduced in the last part of Eric Evans' book _**Domain Driven Design**_.
|
||||
Designing distributed applications needs to be done wisely. Strategic Domain-Driven Design (DDD) is an approach for modeling large-scale applications and systems, introduced in the last part of Eric Evans' book *Domain-Driven Design*.
|
||||
|
||||
Domain driven design is a well-known pattern family and has been established at AOE for quite some time now. Unlike Domain Driven Design, which focuses on the tactical design in an application, strategic domain driven design is an approach that is very helpful for the high-level strategic design of an application and distributed software architecture.
|
||||
Domain-driven design is a well-known pattern family that has been established at AOE for quite some time now. Unlike Domain-Driven Design, which focuses on the tactical design in an application, strategic Domain-Driven Design is an approach that is very helpful for the high-level strategic design of an application and distributed software architecture.
|
||||
|
||||
It is a pattern family focused on using and defining Bounded Context and thinking explicitly of the different relationship patterns and the required "translation" of similar "concepts" between the bounded contexts. It is helpful to argue and find a good strategic architecture in alignment with the requirements, the domain and by considering Conway's Law.
|
||||
A context map and a common conceptional core help to understand and improve the overall strategic picture. Especially with the [Microservice](/methods-and-patterns/microservices/) approach, it is important to define and connect services following the low coupling - high cohesion principles by idendifying fitting bounded contexts.
|
||||
It is a pattern family focused on using and defining Bounded Context and thinking explicitly about the different relationship patterns and the required "translation" of similar "concepts" between the bounded contexts. It is helpful to argue and find a good strategic architecture in alignment with the requirements, the domain, and by considering Conway's Law. A context map and a common conceptual core help to understand and improve the overall strategic picture. Especially with the Microservice approach, it is important to define and connect services following the high cohesion - low coupling principles by identifying fitting bounded contexts.
|
||||
|
||||
The following chart gives an overview of possible relationships between bounded contexts:
|
||||

|
||||
|
||||
While we have found that this approach is especially useful in designing distributed systems and applications with [microservices](/methods-and-patterns/microservices/), we have also extended this approach to provide guidelines for general enterprise architectures.
|
||||
While we have found that this approach is especially useful in designing distributed systems and applications with microservices, we have also extended this approach to provide guidelines for general enterprise architectures.
|
||||
|
||||
Reference in New Issue
Block a user