DEV Community: geraldcroes

Kubernetes & Traefik 101— When Simplicity Matters

geraldcroes — Wed, 08 Aug 2018 16:47:00 +0000

The tutorial that would have spared me hours of struggling with my keyboard

Have you ever been in a situation that started with …

Someone at work: “Look, it’s super simple, let me explain …”

… that continued with …

[ … agony of arcane jargon …]

Same enthusiastic colleague: “See, did you get it?”

You (poker face): “Sure, gotcha, aha, no problem, whoo, super simple indeed, aha … ”

… but that ended up with you sneaking into the bathroom to babble chunks of keywords you barely remember.

“Ok Google, what is a cluster of Ingress in a cube of nodes? … Please please please help me.”

Nope. Hasn’t happened to me. Not even once. No Sir!

But let’s pretend that it did happen (hypothetically) several years ago, and that all the articles I stumbled upon during my research were made of such cryptic symbols that tears started to come out of my eyes (and they weren’t tears of joy).

I said: Let’s pretend.

So based on this fictional situation, let’s try to write the easiest tutorial that involves setting up Traefik as an Ingress Controller for Kubernetes. (And I promise: I will explain everything that is not obvious.)

You can skip this part if you’re familiar with Kubernetes.

What You Need to Know about Kubernetes

Kubernetes, as in Cluster

Kubernetes is a cluster technology. It means that you will see a cluster of computers as one entity. You will not deploy an application on a specific computer, but somewhere in the cluster, and it’s Kubernetes’s job to determine the computer that best matches the requirements of your application.

Machines in the cluster can have different characteristics

Nodes

Each computer in the cluster is called a node. Eventually, the nodes will host your applications. The nodes can be spread throughout the world in different data centers, and it’s Kubernetes’s job to make them communicate as if they were neighbors.

Nodes are machines in the cluster

Containers

I guess that you are already familiar with containers. Just in case you’re not, they used to be the next step of virtualization, and today they are just that: the de-facto standard for virtualization. Instead of configuring a machine to host your application, you have your application wrapped into a container (along with everything your application needs — OS, libraries, dependencies, …) and deployed on a machine that hosts the container engine which is in charge of actually running the containers.

Containers technically don’t belong to Kubernetes; they’re just one of the tools of the trade.

Container embed the required technologies

Basically, Kubernetes sees containers like in the following diagram:

The container engine is responsible for handling the underlying technologies needed in your containers

Pods

Because Kubernetes loves layers, Kubernetes adds the notion of Pods around your containers. Pods are the smallest unit you will eventually deploy to the cluster. A single Pod can hold multiple containers, but for the sake of simplicity let’s say for now that a single Pod will host a single container.

So, in a Kubernetes world, a Pod is the new name for an instance of your application, an instance of your service. Pods will be hosted on the Nodes, and it’s Kubernetes’s job to determine which Node will host which Pod.

If a Pod consists of multiple containers, they will share the same resources / network

Deployments

Here comes the fun part! Deployments are requirements you give to Kubernetes regarding your applications (your Pods). Basically, with deployments you tell Kubernetes:

Hey Kube, always keep 5 instances (or replicas) of these Pods running — always.

It’s Kubernetes’s job to ensure that your cluster will host 5 replicas of your Pods at any given time.

Kubernetes is responsible for deploying the pods to the right places

Services

Oh, yet another fun concept …

Pods’ lifecycle are erratic; they come and go by Kubernetes’ will.

Not healthy? Killed.

Not in the right place? Cloned, and killed.

(No, you definitely don’t want to be ruled by Kube!)

So how can you send a request to your application if you can’t know for sure where it lives? The answer lies in services.

Services define sets of your deployed Pods, so you can send a request to “whichever available Pod of your application type.”

When requesting your application, you don’t care about its location or about which pod answers the request

Ingress

So we have Pods in our cluster.

We have Services so we can talk to them from within our cluster. (Technically, there are ways to make services available from the outside, but we’ll purposefully skip that part for now.)

Now, we’d like to expose our Services to the internet so customers can access our products.

Ingress objects are the rules that define the routes that should exist.

Ingress objects are the rules that define the routes to our services

Ingress Controller

Now that you have defined the rules to access your services from the outside, all you need is a component that routes the incoming requests according to the rules … and these components are called Ingress Controllers!

And since this is the topic of this article — Traefik is a great Ingress Controller for Kubernetes.

What You Need to Know about Traefik

It rocks.
It’s easy to use.
It’s production ready and used by big companies.
It works with every major cluster technology that exists.
It’s open source.
It’s super popular; more than 150M downloads at the time of writing.

… oh? Is my opinion biased? Well, maybe … but all of the above is true!

Let’s Start Putting Everything Together!

This is the part where we actually start to deploy services into a Kube cluster and configure Traefik as an Ingress Controller.

Prerequisite

You have access to a Kubernetes cluster, and you have kubectl that points to that cluster.

Just so you know, here I’m using Kubernetes embedded in Docker for Mac.

What We’ll Do

We’ll use a pre-made container — containous/whoami — capable of telling you where it is hosted and what it receives when you call it. (Sorry to disappoint you, but I can confirm we won’t build the new killer app here^^)
We’ll define two different Pods, a whoami and a whoareyou that will use this container.
We’ll create a deployment to ask Kubernetes to deploy 1 replica of whoami and 2 replicas of whoareyou (because we care more about others than we care about ourselves … how considerate!).
We’ll define two services, one for each of our Pods.
We’ll define Ingress objects to define the routes to our services.
We’ll set up Traefik as our Ingress Controller.

And because we love diagrams, here is the picture:

Setting Up Traefik Using Helm

Helm is a package manager for Kube and, for me, the most convenient way to configure Traefik without messing it up. (If you haven’t installed Helm yet, doing so is quite easy and fits in two command lines, e.g. brew install kubernetes-helm, and helm init.)

To set up Traefik, copy / paste the following command line:

helm install stable/traefik --set dashboard.enabled=true,dashboard.domain=dashboard.localhost

In the above command line, we enabled the dashboard (dashboard.enabled=true) and made it available on http://dashboard.localhost (dashboard.domain=localhost.domain).

The output of the helm install command line will look like:

In my case, EXTERNAL-IP is already available and is localhost.

EXTERNAL-IP is the address of the door to my cluster; it is the public address of the Ingress Controller (Traefik).

And as we said before, we should be able to access the dashboard right away!

The dashboard shows that Traefik has detected a service (called dashboard.localhost, on the right) and has created a route to it (host:dashboard.localhost, on the left)

Let’s Deploy Some Pods!

Now it’s time to deploy our first WhoAmI!

As a reminder, we want one Pod with one container (containous/whoami).

Quite a straightforward Pod

Kubernetes uses yaml files to describe its objects, so we will describe our deployment using one.

To provide some explanations about the file content:

We define a “deployment” (kind: Deployment)
The name of the object is “whoami-deployment” (name: whoami-deployment)
We want one replica (replicas: 1)
It will deploy pods that have the label app:whoami (selector: matchLabels: app:whoami)
Then we define the pods (template: …)
The Pods will have the whoami label (metadata:labels:app:whoami)
The Pods will host a container using the image containous/whoami (image:containous/whoami)

📗 Note: You can read more about deployments in the Kubernetes documentation.

Now that we have described our deployment, we ask Kubernetes to take the file into account with the following command:

kubectl apply -f whoami-deployment.yml

And let’s check what happened with:

kubectl get all

The whoami-deployment has been created

Let’s Define a Service!

If you remember correctly, we need services so we can talk to “any available Pod” of a given kind.

We need the whoami service to refer to our whoami pods

Once again, we need to define the object:

Some explanations:

We define a “service” (kind: Service)
The name of the object is “whoami-service” (name: whoami-service)
It will listen on port 80 and redirect on port 80 (ports: ...)
The target Pods have the label whoami (selector:app:whoami)

📗 Note: You can read more about services in the Kubernetes documentation.

Now that we have described our service, we ask Kubernetes to take the file into account with the following command:

kubectl apply -f whoami-service.yml

And let’s check what happened with:

kubectl get all

Our service is available!

Ingress

At last, we’re about to define the rules so that the world can benefit from our (kick-ass) service.

You know the drill, let’s write the YML file to describe the new object:

Some explanations:

We define an “ingress” (kind: Ingress)
The name of the object is “whoami-ingress” (name: whoami-ingress)
The class of the Ingress is “traefik” (kubernetes.io/ingress.class:traefik). This one is important because it tells Traefik to take this Ingress into account.
We add rules for this Ingress (rules: …)
We want requests to host whoami.localhost (host:whoami.localhost) to be redirected to the service whoami-service (serviceName:whoami-service) using http (servicePort: http).

📗 Note: You can read more about Ingress in the Kubernetes documentation.

Now that we have described our Ingress, we ask Kubernetes to take the file into account with the following (same old) command:

kubectl apply -f whoami-ingress.yml

And now, since Traefik is our Ingress Controller, let’s see if something has changed in the dashboard …

Traefik has automatically detected the new Ingress!

That’s it, no reload, no additional configuration file (there were enough). Traefik has updated its configuration and is now able to handle the route whoami.localhost!

Let’s check …

Traefik redirects the requests as expected

Yes, our service is useful, but its UI could use a bit of love ❤️

Here, we confirm that Traefik is our Ingress Controller and that it is ready to bring its features to your services!

May I Ask For Load Balancing in Action?

Earlier, we talked about a WhoAreYou deployment with 2 replicas.

Let’s do it in just one file :-)

There is not much to say here, except that this time we have 2 replicas … (replicas: 2)

So let’s ask Kubernetes to apply our new configuration file.

kubectl apply -f whoareyou.yml

And let’s go right away to Traefik’s dashboard.

And voilà!

Traefik detects the new Ingress and the two available Pods in the Service

First request, one of the Pod replies

Second request, the other Pod replies

Conclusion

If I had wanted to write an article that dealt with “just” configuring Traefik as an Ingress Controller for Kubernetes, well, it would have fit in one line:

helm install stable/traefik

Because it’s actually the only configuration operation that we’ve needed in the article. The rest is just explanations and demos.

Yes, this step was indeed as simple as that!

Go Further With Traefik!

Now that you know how to configure Traefik, it might be a good time to delve into its documentation and learn about its other features (auto HTTPS, Let’s Encrypt automatic support, circuit breaker, load balancing, retry, websocket, HTTP2, GRPC, metrics, etc.)

Containous is the company that helps Træfik be the successful open-source project it is (and that provides commercial support for Traefik).

Follow me & Træfik on Twitter :-)

Your comments & questions are welcome!

You can clone the files from my github repository geraldcroes/kubernetes-traefik-article.

From Chief Enterprise Architect to Developer

geraldcroes — Tue, 27 Feb 2018 18:04:02 +0000

Photo by Gerald Croes — Mini World Lyon

You’ve read the title right, I’ve quit my (dream) job — CEA — for a new job — developer.

Now, I’ll wait a minute for the information to sink in.

…yes, that’s what I did.

All things considered, I might need a minute for myself too.

…Ok, that’s what I did.

Seriously, how did that ever happen?

I think that it has to do with the way I got involved in IT.

Years ago, I stumbled onto programming thanks to laziness — a native skill I managed to nurture to undiscovered levels of mastery back when I was a teenager.

Because I didn’t like wasting my time doing homework (who does?), I was drawn to buy a fancy calculator that had far more buttons than one would need to pilot a plane. “If it has more buttons, it must do more things.” Laziness having its limits, guessing the roles of each button turned out to be quite ineffective, so I had to (grudgingly) open the 500-page manual … where a chapter caught my attention — Programming Your Calculator.

Of course, buying a calculator doesn’t make you an “IT guy/gal”, at least no more than having acne during your teens or being socially awkward when standing in a 5-meter radius of a person of the opposite sex (even if both can help).

So the extra factor that came into play was my math teacher who, casting a glance at my new device, stared at me with a smirk, “Don’t put high hopes in that because it will prove to be useless when working on matrixes. I’m interested in the reasoning, in every step leading to the result, not by the result itself.”

Challenge … accepted!

No, the matrix wouldn’t have me.

So I eagerly went back to the manual and started to learn programming. If it were possible, I would make that show every step leading to the result.

And guess what?

Worked like a charm.

I managed to get the maximum mark for the test (in 15 minutes instead of the four scheduled hours), and I also managed to get calculators banned for the entire class. (No, didn’t see that coming.)

Anyway, I was hooked. I started to program everything I was taught instead of talking regular notes (whether I would have the calculator for the tests or not). The funny thing is that my math teacher and I started to get along together because I had been transformed into the most benevolent student, asking questions about every detail and edge-case about the formulas we were taught.

At the end of the year, I had become good at working harder to do less … although in the end I am not sure if I actually worked less than if I had been willing to do more.

The story could have stopped there and then, but one day, as I was facing every students’ dreaded conundrum (What do you want to do in the future?), I discovered the most unbelievable thing— “You know, if you like programming, you could do that for a living … I mean … work in IT.”

Developer was an actual job. People were getting paid for programming.

Not so dazzling when you remember that kicking in a ball is also a job, but great news nonetheless for someone who has two left feet.

Anyway, I went to an IT school and learned programming (for real).

“Choose a job you love and you’ll never have to work a single day.”

After graduation, I joined a consulting agency and worked on many different projects.

Out of habit, I kept working during my free time to get rid of tasks I didn’t enjoy during the day. I learned new (and more concise) programming languages, I developed an IDE with code completion and macro recording, I wrote a framework that handled routing, security, templating and that had an embedded ORM, I tinkered with a dependency injection framework, I met design patterns, I programmed code generators, packaged reusable modules, designed a content management system, and so on.

I did all this during my free time … so I’d have more fun during work hours.

And since I had gathered so much experience (working extra hours), I started to share my knowledge with my teammates … and it became part of my new job.

Habits being habits, I started to read books about optimizing teamwork, learned about agile methods, about dozens of tools that would help us improve our delivery … and since I had managed to put all this together … it became part of my new job.

Habits being habits … well, you get the drill … it became part of my new job … and I ended up being CEA.

But the more I became involved in business and management, the more I began drifting away from code. The more I was using the whiteboard, the more wistfully I looked at my keyboard. The more I was a CEA, the less I was in touch with why I got involved in IT.

But one day, a friend of mine disclosed the most unbelievable thing — “You know, if you like programming so much, it’s still a job … ”

So it became my new job, and I’m quite excited.

The Good (Tweak), the Bad (Mac), and the Ugly (Terminal)

geraldcroes — Sun, 25 Feb 2018 17:11:09 +0000

I’ve switched to Mac … for work …

There, I’ve said it.

It feels like confessing a fault. A confession where forgiveness doesn’t ensue. A confession where what follows is contempt, contempt in my (Linux-minded) colleagues’ eyes. So I’ll just give them a good reason ...

… and so far I’m enjoying it.

Even though I’m a big Linux fan, I’m used to working with a bunch of applications that are not available there, and the Mac (despite the steep price) appeared as an alternative to the virtual-machines hell. Far from being perfect, it’s a good balance between a Unix system and an end-user general-purpose machine.

However, coming from Linux, the jarring out-of-the-box experience with the terminal was a shock. The default setup is just plain terrible — outdated, no autocompletion, no colors … no fun.

But after a few tweaks I’m feeling at home, and this article is all about sharing configuration options so that people like me will keep enjoying their beloved command lines.

Here is our starting point.

People don’t like the terminal … you don’t say!

Step 1 — Homebrew

Because there is a life beyond the App Store, your first step on Mac should be to install Homebrew. It’s not mandatory; it just makes your life easier (you decide).

According to its website, Homebrew is the “Missing package manager for Mac.”

In Linux words, it’s our apt, yum, dnf, or pkg (depending on where you come from).

Installing Homebrew is a one-liner:

Done, but Nothing Has Changed

Exactly, nothing has changed, except that you’ll be able to install, update, and remove the other tools we’ll talk about in a minute.

Step 2 — Update Bash to Version 4.4

Supposedly because of licensing issues (GPLv2 vs. GPLv3), the bash that comes with our Macs is stuck in 2007 (version 3.2).

Let’s fix this and update to version 4.4 (at the time of this writing).

brew install bash

Yes, it’s that simple.

Configure Bash 4.4 as Your Default Bash

Now that you have the newer version of Bash installed, you need to tell your terminal to use it instead of the default login shell.

Open the terminal preferences and set the “Shells open with” option so that it points to your new best friend, /usr/local/bin/bash, which is the location where Homebrew has installed it.

Then, for a reason I have yet to understand, you need to add that same path to your /etc/shells file. If you don’t, you might stumble upon small issues (e.g. I wasn’t able to make my terminal play along with Alfred).

Restart your terminal and type bash --version to check that everything works as expected (you can also try to echo $BASH_VERSION).

The terminal now has Bash 4.4 by default.

Step 3 — The Colors of Bash

To steer clear of the dim monochrome corner Apple wants you to stay in, enable the colors.

vi ~/.bash_profile

Take this new configuration file into account (source ~/.bash_profile) and see for yourself :-)

Before

Life in green.

After

Not much on this screenshot, except that the colors for directories and regular files are now different.

Step 4 — Autocomplete Time

It’s time to allow your fingers to rest and let them enjoy the power of the tab key for a bit of auto-completion (that goes beyond file names).

brew install bash-completion

Now update your .bash_profile (vi ~/.bash_profile), and add the following line

[-f /usr/local/etc/bash_completion] && . /usr/local/etc/bash_completion

If you need autocompletion for Git, you’ll need to install or update it (the version provided with XCode doesn’t work with the completion).

brew install git

And as usual, restart your terminal if you want to test it right away.

Step 5 — May I Ask for a Git Prompt?

If you use Git, the one thing still missing from your now-good-looking terminal is a Git prompt with the state of your repository and the branch you’re on.

Once again, you’re just a single brew command away from the solution.

brew install bash-git-prompt

To load its configuration at startup, you need to add the following lines into your .bash_profile file.

vi ~/.bash_profile

You now have a nice Git prompt you can configure to your taste.

What It Looks Like in a Non-Git Directory

The green tick means that the last command has been successful.

What It Looks Like in a Git Directory

You can see that I’m on the master branch and that everything is synchronized with the distant repository.

Tune It a Bit More

The bash-git-prompt package comes with multiple configuration options. To test them out, you can create a ~/.git-prompt-colors.sh file. For what it’s worth, here is mine below.

My Pimped Out Terminal

With a pinch of transparency and a nice background texture, here is what my own terminal looks like.

I hope you’ve enjoyed the tour and that you have learned a trick or two to make your terminal a better experience.

You can download my configuration from Github.

If you have some tips you’d like to share with a new Mac user, make sure to add them in the comments section.

DDD 101 — The 5-Minute Tour

geraldcroes — Sat, 24 Feb 2018 05:17:34 +0000

I like crazy challenges.

During a conference in Paris, after the organizers asked me to fulfill a missing-speaker slot for a lightning talk (an hour before the presentation time), not only did I accept, but I decided that an introduction to DDD (Domain Driven Design) was a good choice. Yes, DDD — the discipline that was born in a 560-page book.

Unfortunately, even if I had managed to get the attention of a room crowded with (PHP!) developers to talk about a topic that was dear to my heart, I don’t know if the presentation insisted enough on the two key aspects that are DDD.

My goal with this article is to give it another try, with more time to prepare.

DD What?

Before you leave, driven away from this article by your acronym-o-phobia syndrome, you might want to know that DDD is full of shiny new design patterns. Design patterns … The funny thing is that they are the reason why I was drawn into this world in the first place … and the funniest thing is that they are the least essential elements in that world.

So, What Is DDD?

When I’m using my keyboard, cradled by the sound of the stroke keys, I like to understand the code I’m writing (easy), to understand the code I wrote the day before (less so), to understand the code I wrote six months before (challenging), and the satisfaction that tops the list is to see other developers understand the code I wrote.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

— Refactoring: Improving the Design of Existing Code, 1999

My best memory on the subject happened years ago. At the time, I had asked a developer in the team to add a feature to the application. I didn’t give her many details about how the code was organized, and when she came back, a bit puzzled, she asked for confirmation, “All I have to do is to add some lines here and there … and I’m done, right?”

She couldn’t have been more right. It was amazing to know that the object model I had come up with worked just as expected — on the first read.

To me, that’s what Domain Driven Design is all about — expressing a meaningful object-oriented model that says what it does.

DDD reminds you of common sense rules, and it offers a set of ideas, principles, and patterns to make it happen.

What Sets DDD Apart From Standard OOP?

Good question — nothing.

DDD is nothing more than OOP applied to business models. (You’ll prove me wrong when you dive deeper into DDD, but let’s accept that as an answer for now.)

I’ll use my personal experience to try to explain why I believe that DDD is plain OOP.

When I first learned about DDD, I was already an enthusiastic OOP practitioner, and I used to advocate about OOP a lot (giving talks, practicing pair reviews, and so on).

Even though at the time I was considered a satisfactory developer, I knew deep down that something was wrong with my code, something I couldn’t figure out, something that had to do with my inability to write meaningful unit tests that covered the business rules. I knew that the tales my code were telling were not as expressive as I wished they were.

But since no one seemed to complain, I kept learning patterns, and patterns, and patterns.

Before I bought the “blue book” (Domain Driven Design: Tackling Complexity in the Heart of Software), I scanned through the pages and saw factories, repositories, value objects, entities, and this incredibly appealing schema that would lure any geek’s attention.

They alone convinced me to invest my time (and money) into the book. Even though I was eager to learn about new fancy patterns, I managed to contain my impatience and read the introduction.

The Ubiquitous Language

I don’t remember every word of this infamous reference, nor do I remember every rule, but I remember being hooked right from the beginning. The concept of the ubiquitous language was a revolution.

Despite a convoluted designation, the idea is straightforward — call a spade a spade. And the underlying rule is, “To know what a spade is; how to use it; what it does … ask someone who knows.”

Oh, my! Did you enjoy the book just because of this?

Well, it might sound obvious, but this was the main issue that impaired my ability to write self-explanatory code. Don’t mock me, I can say from experience that I wasn’t alone (and that not everyone has been cured).

How many of us, developers, have just peeked at the requirements only to start coding right away? How many programmers have skimmed through the business rules to jump on the framework-y and database-ish aspect of the project? Don’t pretend — I know for sure!

I can’t blame us. These requirements are often a bland and boring read, at least as bland and boring as it is to write them (it’s called karma).

Good news is that it doesn’t have to be this way.

Only What You Understand Can You Explain

To be able to solve a problem, I have to understand it (along with its intricacies).

If you can’t explain it to a six-year-old, you don’t understand it yourself.

— Albert Einstein

The corollary to that is, “To understand a problem, I have to interview the people that are dealing with it.”

Agile Methods Certified

“Talking to the right people.” That sounded familiar.

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

— The Agile Manifesto

Of course, if you took programming because you’d rather talk to computers over human beings, that can be a harsh truth to swallow. But, if you were looking for the perfect occasion to socialize and stop acting like an IT Crowd stereotype, good news, here is your chance.

No More Dull Projects

“Talk to business people; they’ll enjoy explaining their jobs and problems, you’ll love listening and finding solutions.”

It literally changed my vision of IT.

As a young developer, thrilled by the idea of crunching technical puzzles, I was often disappointed by the lack of challenges brought by real-life projects. No, calculating a price for an insurance plan is not what I call challenging … nor is finding the cheapest hotel room on a given date … you only spend time writing something you’ve figured out in seconds.

But when you talk to the business people who need your skills to find a solution and save some time or increase the quality of their output, it all becomes interesting because you get a sense of purpose. Not only will you write the code for the solution, but you will be part of the solution itself, you’ll know its whys, whats, and whens … and the challenge will be to write it in a way that exposes that very purpose.

i Shall Not Pass! (Nor Should j or x.)

“You should name a variable using the same care with which you name a first-born child.”

― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

The above quote resonates even more with the ubiquitous language concept. Each class, each method, each variable should be carefully named so that the story they tell is the business story you’re writing. And heed DDD’s words, “These names should be agreed on with the business.” Why? Because in the future, when you talk about a new feature or a bug report, you’ll understand each other. The code reflects business reality.

If anyone ever needs to be persuaded that meaningful variable names are mandatory, just ask them.

Which of the following would you rather read?

To this day, no one has ever missed the point … except for one person, “Nope, I would never ever write or read anything in PHP.”

Health Check — Anemic or Not?

But let’s go back on track. We’ve said that DDD was OOP applied to the business model. Naturally, after I had read the book, I asked myself this simple question.

“Is my object model a real object model? Or is this procedural code in disguise?”

And I realized that I used to focus all my efforts on the data, without proper dedication to the processes that come along, and that I suffered the anemic model syndrome.

The fundamental horror of this anti-pattern is that it’s so contrary to the basic idea of object-oriented designing; which is to combine data and process them together. The anemic domain model is just a procedural style design […]. What’s worse, many people think that anemic objects are real objects, and thus completely miss the point of what object-oriented design is all about.

— Martin Fowler — Martin Fowler’s Bliki

To self-diagnose my code’s disorder, I asked myself, “Can I replace all my objects with hashmaps? Will my code work after that?” And the answer was a stark yes.

I had developed the habit of setting apart data and intelligence — which is contrary to the creed of object-oriented programming — which explained why I often ended up having hundreds of services manipulating dumb data objects … with fat controllers trying to orchestrate the resulting mess.

DDD’s rule of thumb — Bind data and intelligence together …

… And Set Boundaries to Keep Them Apart

At this point, two major concepts had finally sunk in — I was talking to business people so that the code would reflect their problems, and I was modeling the solution using real objects.

Though, as the project grew, I still had two hurdles to overcome: conflicts and complexity.

Conflicts when we tried to find names for similar concepts used in different contexts, and complexity as the model started to include more intelligence.

The easiest-to-explain example that comes to my mind is Client.

ClientForTheLogisticTeam, ClientForTheMarketingTeam, ClientForTheAccountingTeam, …

The problem at hand was that Client was the actual name used by the business teams, but that very name implied rules and constraints that depended on the context. Our first reflex was to differ from the real names, but the rule is to stick to the business vocabulary.

Then, we remembered another key point of DDD — Bounded Contexts.

Bounded contexts are the Single Responsibility Principle applied to your domain model. Each part of your system has its intelligence, data, and vocabulary. Each part is independent of one another.

Is It Time We Talk About Patterns?

Oh, patterns … I had almost forgotten.

Yes, DDD brings its lot of patterns. Brace yourself; you’re on the brink of learning them in a breeze.

You model your business using Entities (the ID matters) and Value Objects (the values matter). You use Repositories to retrieve and store them. You create them with the help of Factories. If an object is too complex for a single class, you’ll create Aggregates that will bind Entities & Value Objects under the same root. If a business logic doesn’t belong to a given object, you’ll define Services that will manipulate the involved elements. Eventually, when the state of the business changes (a change that matters to business experts), you’ll publish Domain Events to communicate the change.

There you are, we’ve talked about DDD patterns!

**But in the End … This Is DDD**

The rest is not important.

Kotlin Fun With The Factory Pattern

geraldcroes — Sun, 10 Dec 2017 20:09:37 +0000

When you read “let’s have some fun with the factory pattern”, I agree that you should doubt the writer’s enthusiasm and see for yourself. But, as I was writing some code to play with this language I’ve recently fallen in love with, I asked myself, “How should I write a factory method?”

This simple question led me to some experimentations.

Ok to have some fun, but … what’s a factory?

For those in need of a reminder, the factory is a creational pattern listed in the book commonly referred to as “the GOF”. If you haven’t heard or read about it, there’s still time to catch up. If it falls in the TL;DR category, don’t hesitate to google the world of patterns; there are plenty of resources available on the internet (and Wikipedia is a satisfactory one for a quick introduction).

The factory’s goal is to deliver a ready-to-use object to its client. The factory hides the complexity of creating and selecting the right object for the job.

As we’re all fond of UML, I’ll sketch something that vaguely looks like UML (on a Saturday night) so we’re on the same page.

The Factory as it is in the GOF

Now that we all remember what a factory is (I know you knew it — but just in case), let’s write the first candid Kotlin implementation.

Say we have a product called a FileParser that we need so that we can read information from files we would otherwise be oblivious to.

And let’s say that we have two available implementations of this FileParser, one dedicated to understanding XML (XmlFileParser) and one dedicated to understanding JSON (JsonFileParser).

So we’re done with our products description.

The client (our program) will need one of the two available implementations. To make the right choice, the logic is to test the filename and test its extension. If it’s “.xml”, use XmlFileParser, if it’s “.json”, use JsonFileParser. To avoid testing this everywhere in the code, we have decided to use the factory pattern that, thanks to its createFromFileName(fileName: String) method, will give us the correct FileParser…

…which is implemented at lightning speed thanks to Kotlin.

There we are — we have a to-the-letter implementation of a factory in Kotlin.

If we wanted to use the factory, we’d have written:

You said it would be fun…

Yes, I know what I said, so let’s keep diving into the subject.

What’s a bit boring with our factory is that we need to instantiate it. It’s not a lot of lines, but still. I’d love to be able to write something like

One line shorter … yes … it’s worth it!

The syntax looks like a static call, but as there is no “static stuff” in Kotlin, we’ll use a different trick — companion object. These objects are kinds of singletons attached to the class (see companion objects in the documentation).

Now we can use the previous syntax, and it’ll work. But the caveat is that we can no longer call the createFromFileName method from an instance of our FileParserFactory, only from the class itself with a static-like call.

And if you carefully read the code, you’ll see that our class doesn’t implement FileParserFactory, our companion object does.

Of course, we could write a sort of synonym for our instance to be able to expose such a method, but that would be ruining the concept. See for yourself:

If you’re asking yourself, “What’s wrong with having the static syntax as your only option?” I’ll answer with the simple, “It’s wrong because you can’t pass an instance of your factory to another object. Every client of the factory will have to be hardwired to the implementation of your CompanionObjectFactory.”

So … are we having fun yet? Just asking.

Er … Ok, let’s try another syntax.

If we still want to save a line of code while creating our FileParser, we can use another Kotlin feature, which is the object keyword. The object keyword is a way of asking your code to ensure that only one instance of a class will be available at any time in the life cycle of your application.

Let’s see how it’s done.

Yes, we’ve just replaced the class keyword by the object keyword.

From now on, we can use the one line option along with the possibility of calling the method from the instance itself.

I’m thrilled, my head is spinning right now…

Man you’re tough. Let’s try to spice things up then.

So, we have these FileParserFactories that handle the creation of FileParsers. That’s nice, but it would be nicer if we could embed the factory within the FileParser interface itself. Good news: in Kotlin, we can add a companion object to an interface.

Isn’t that fun? (At least for someone who comes from Java.)

Once again, we cannot give the factory instance to another object, but … is it still needed as the interface itself embeds its own factory? I agree that this very question is open to debate (because I do not fully agree with myself right now — I’m just getting carried away with the Kotlin syntax).

But if I need a different factory? How can I…

Hey! Excellent question.

The super fun thing with Kotlin is that you can add extensions to existing code. So if you need to write your specific factory, you can add it like this:

Yes, you’re “adding” a new method to the companion object within the interface, so from now on you will be able to call the new factory (fromFile) you’ve just declared.

More fun with a fun syntax

Imagine that you could write

Well, actually you can, by adding the keyword infix before your extension :-)

Infix means that you don’t need to call the method using the traditional syntax, you can call it the fancy way.

Well yeah … why not a factory method in the String itself?

You don’t say! Let’s do this :-)

So we can now create a FileParser using this syntax

That’s all the fun you’ll get for now

I’m sure there are many other ways to write crazy factories in Kotlin, but I was happy to share these ideas as I played with the language. If you want to tinker with the examples, you’ll find them in this GitHub repository.

Don’t hesitate to share your ideas (or your rants, as you wish!) in the comments.

Don’t Use Design Patterns!

geraldcroes — Tue, 05 Dec 2017 17:42:25 +0000

Don’t Use Design Patterns, but Know Them — Master Them!

Behind this catchy title (sorry) lies one of my dearest pieces of advice, nurtured by unfortunate experiences with enthusiastic developers that had just learned about patterns after a training session. How many times have I reviewed lines of code littered with useless classes and cluttered with pointless abstractions? I don’t want to know. (And I don't want to know how many times I was the culprit.)

Never, never try to put design patterns in practice. Never try to include them into the design of your new application. Don’t engage in aggressive refactoring to add patterns in any existing code for the sake of “making it look better,” or for the sake of flexibility, “so the code will be easier to update in the future.”

However, study them, understand them, re-read them, think about them and give them some attention.

The Metaphor Game

If I Were a Pianist

Design patterns would be my scales. Scales develop finger nimbleness and train the spirit. Pianists have to know them, but scales aren’t music.

Imagine the surprise of the audience if, during a performance in a trendy auditorium, they read in the program, “Major scales played on a 3-beat rhythm followed by a playful syncopated minor scales inventory.”

Similarly, if a composer went through the Moonlight Sonata to refactor the piece by inserting a bland C# scale to ease the cramps of the interpreter’s fingers ... that would be the most terrible answer to a non-existent problem.

If I Were a Chess Player

Design patterns would be the problems I solve scanning the newspapers, magazines or dedicated books: These puzzles highlight tactical aspects of the game such as deflection, pin, decoy, passed pawns, sacrifice, overloading … but they aren’t the game, they are just a tool that helps me learn a subset of chess. I couldn’t become a grand champion if I only studied tactics.

Of course, being a great tactician helps. Knowing tactics helps you find solutions you’d otherwise be oblivious to. But if all I tried to do during my games were to sacrifice my pieces for no reason beyond the fact that it is a tactical aspect of the game (and yet one of the most brilliant ones), I’d end up being a terrible chess player — and nobody would call my style romantic, just plain dumb.

No More Metaphors

Design patterns are fantastic when correctly put into practice. They help us when they are an additional source of inspiration but not a destination, not an end.

Design patterns let developers discuss possible solutions to common problems. They demonstrate simple study cases that are easy to understand and easy to put into practice into more substantial project, into real life designs. Put together, they form architecture catalogs that will welcome beginners and experts alike. They train us on specific and diverse aspects of object-oriented programming.

Each pattern ought to be used if and only if it fits the problem at hand. Not keeping this in mind will make our code sick and we’ll soon see known diseases such as “Singleton-aches,” along with “OnlyTheFormerDeveloperKnowsAboutThisObfuscatedCode.”

A pattern is not a defined and immutable solution. A pattern is by no means an implementation. It explains how to overcome common hurdles we'll find on our path.

Don’t let patterns guide you. Don’t seek to transform your problem so it fits your pet pattern, or you’ll end up writing mediocre solutions to problems you didn’t even have.

KISS — Keep It Simple, Stupid.

The most elegant solution is the simplest one, the easiest to understand.

Not a single “Hello World!” example justifies the use of a pattern, and no “Hello World” example corresponds to a user need. Hello World might even have become a pattern in itself — its sole intent being, "to give a glimpse of a new technology to developers." But no one teaches developers a new technology exclusively using, “Hello World!”

If a problem has two solutions, one that fits in ten lines of code, and another one with hundreds of lines of code along with a pattern, please consider not using the pattern. Their presence isn’t a quality measurement.

Of course, if your program is littered with the same ten lines scattered around, it might be time to reconsider.

But if …

Never develop for “if something happens … ” Develop because of your current problem. Developing for a blurry hypothetical future is the best way to transform a two-day project into a two-month project. If you happen to justify the presence of a pattern in your code only through a “you know, if … ”, then remove the pattern.

REST 101

geraldcroes — Sun, 03 Dec 2017 11:45:10 +0000

There was a time when REST was a revolution. The premise of a new world where SOAP problems would be washed away. (I went on a slippery road with that play on words, didn’t I?) REST is now a defacto standard that is starting to lose its momentum (or maybe has already lost a lot of it). For some of us, it still holds a particular place in our mind, our first true love. This journey when we discovered interoperability that worked. For others, starting out in development, it represents a standard that doesn’t belong to the vanguard anymore, something from the past, a legacy, something they don’t want to invest their time in — it’s just there.

Yes, there are other solutions today aside from web services in REST and JSON, lots of them. There are even multiple REST comprehensions out there, and I already know that by writing this article, I might trigger a nerd war about what is an authentic REST architecture. People will start to raise Roy Fielding’s 2000 dissertation as proof. And to be honest, I’ve done my share of fighting over such ideas, but that time has passed. After having worked for so many years in the industry, I consider myself as just a developer, a regular developer. So, I won’t pretend that I write the truth. I’ll just write what I’ve done and seen for the past years, in practice, at work, out there.

REST 101

If I needed to explain REST to my relatives in just one sentence, I’d say, “It’s a way of making applications talk together,” no more, no less. If I wanted to go further (knowing I’d lost them in the process), I’d add, “It’s a way of structuring the dialogue between multiple applications.” Just like an orchestra conductor expects the first violin to be on his left and the cello to be on his right; as a developer, you expect a REST architecture to follow some guidelines to find what you’re looking for quickly.

When you write an application, your goal is to solve your user’s problem, whether they’re bored (so you write games), overwhelmed (so you write reminders, calendars, to-do lists), creative (well, you got the idea), and so on. There are times when the application itself will have its own problems to solve (for example, getting the GPS coordinates from an address). There are other times when the application will be able to solve other applications’ problems (for example, you’ve written a a grammar checker, a word count, a dictionary or a thesaurus). So at one point or another, you might want your application to ask for a service from another one, or you might entice another application to get its answers from yours. There are many methods at your disposal to enable the communication between two different (and distant) applications, and there are even books dedicated to this matter. REST is one of them.

REST is a combination of technologies and standards put together. When we say REST, we often have in mind the following:

HTTP,
JSON,
And… that’s it!

Could have been worse right?

So at its root, that’s all REST is.

HTTP, this thing everyone uses

When I tell my friends (well, those who don’t work in IT) that they use an HTTP client almost every day, and that they even have a favorite one, they are often incredulous.

“Yeah, sure, I have a preference for this whatever client you’re talking about.” And they’re often shocked when they realize that they do have a preference because a regular web browser is an HTTP client. What also amazes them (even more) is what’s going on under the hood, when I show them that they can consult the code behind the pages. This internet browser is an HTTP client whose sole purpose is to transform HTML, CSS and Javascript into beautiful pages (or just pages if I were the designer).

So, in a way, everyone knows about web services — Your machine (the client) talks to another machine (the server) using HTTP (the protocol), so the server sends HTML (the response) displayed in your browser window (the feature of your application).

Yes, REST uses the exact same protocol as your browser. But before we talk about the differences, let’s talk about the response itself…

JSON, a humanly readable message

When computers exchange information, they don’t expect humans to read their raw dialogue. This assumption has its advantages because the human brain is not capable of understanding binary files. Surprisingly, this fantastic non-artificial intelligence that is our brain cannot interpret the message if it’s not expressed using chains of characters (how primary). But humans, these stubborn beings, sometimes find it convenient to be able to read the exchange, and JSON is a text format that humans (even beginners) can understand. It’s also one of the most easily readable ones.

Let’s say I have access to a web service available at /service/reservations where I can see the reservations made to my favorite restaurant.

The response should contain the reservation dates, times, and numbers. And it’s precisely what you would find in a typical JSON response.

If you told me that only IT professionals were able to understand this JSON response, I’d be surprised…or I would know that you partied too hard yesterday.

And that’s it

Yes, that’s truly the core of REST — HTTP and JSON. But have we talked about everything yet? Not even close. So let’s keep diving into the subject.

So, web services…what can I do with them?

Let’s go back to the purpose. When a user, through an application, deals with a system, it’s either for querying for its current state, or for updating its current state. You can think hard and try to find different use cases, but you won’t (ok, you won’t, if you agree with me that computing a value falls into the category of querying for the current state that is the knowledge).

Let’s now have a closer look at HTTP. For now, all we did was agree on the fact that your browser was an HTTP client. We’ve also agreed that this browser was dedicated to requesting for the server’s content (the internet). If I was browsing Wikipedia, I could consult a wide variety of pages, answering an even wider variety of questions — what a computer is, what temperature I can expect in Paris in December, who Superman is and what the Matrix is (even if we might not have the full answer for this one). The response would be expressed in natural language and designed with HTML / CSS.

But what if I wanted to contribute? What if I wanted to add my own piece of knowledge to the system? I’d look for a button to switch to editing mode. I’d fix a typo, add a bit of information (something reliable, like that “Superman is the strongest super-hero, no discussion”), add a reference, or rephrase something I found tricky to understand. Once done, I’d want to send it to Wikipedia, and my browser would use the same HTTP protocol to communicate with the server, but would use a different verb.

The HTTP Grammar

Yes, verbs.

Let’s go back to our restaurant and our reservations. Up to this point, what we’ve done is query the system state — What are the known reservations? To send our request, we’ve used our browser. The browser used HTTP and the verb “GET.” (Like, “GET this information for me,” quite easy to remember.)

As we saw before, we’ll also need to update the system, like adding a reservation, changing the time or number of guests for a given reservation, or simply deleting our reservation.

And REST does have the corresponding verbs:

POST: Create a resource,
PUT: Update a resource,
DELETE: Delete a resource,
PATCH: Update properties of a resource,
GET: Read a resource.

But before we can see them in action, we need to talk about the last piece of the puzzle.

Follow the path

Collections

If the verb determines the action, the path (the URL) defines the subject. When we GET /service/reservations, we deal with the whole reservation collection. As a consequence, if we wanted to add a reservation, we would POST to that same URL (the collection) along with a JSON message representing the new reservation.

#Request

POST /service/reservations

With the following sent data

If we consulted the collection right after the insertion, we would get

#Request

GET /service/reservations

#Response

Note that the system has added reservation IDs to the collection items.

A single element

But what if we’d like to get a specific element in that collection? Like, the R3 reservation we’ve just made?

We would specify the element ID, right at the end of the path, like below.

#Request

GET /service/reservations/R3

#Response

Notice that the response is now a single element (starts with the opening curling brace), and no longer a collection of elements (that started with the opening bracket).

We haven’t talked about updating a record?

Yes, let’s do this.

To update a record, we have two choices at our disposal:

PUT (to update the whole document)
PATCH (to update some information)

Let’s start by updating the whole record. The request will look like the one we sent for the creation.

#Request

PUT /service/reservations/R3

Now, let’s suppose we only want to change one of the properties of our reservation. We’ll use the PATCH verb on the same record (same path). When using PATCH, we can send a partial JSON message. Here is what we’d send to change the time we’d like to arrive.

#Request

PATCH /service/reservations/R3

#Sent data

With this record, the time of the reservation will be updated, but the rest of the data will stay untouched.

And one verb to delete them

And last, to cancel our reservation (deleting it), we’d do

#Request

DELETE /service/reservations/R3

This is your first stop

So we’ve gone through the core concepts of a REST architecture. If you’re new to development, a project manager, a business analyst or anyone that has to be in touch with IT but not involved in the development and not involved in fine-grained conceptions of those kinds of services, it should be sufficient knowledge to understand people modeling such architectures.

Quick Recap

We can define REST as a way to enable communication between systems. It stands on HTTP and (for the most part) JSON. We expose services through resources that describe the content of the system thanks to meaningful URLs (collections /resources/, or individual elements /resources/element-id). To manipulate the system, the client uses HTTP verbs on these resources so it can CRUD them (Create, Read, Update and Delete).

If you have any questions, please don’t hesitate to ask in the comments, I’ll do my best to answer. Also, don’t forget that this is the first in a more extended series, and we’ll soon dive deeper into the world of REST!

DEV Community: geraldcroes

Kubernetes & Traefik 101— When Simplicity Matters

The tutorial that would have spared me hours of struggling with my keyboard

What You Need to Know about Kubernetes

Kubernetes, as in Cluster

Nodes

Containers

Pods

Deployments

Services

Ingress

Ingress Controller

What You Need to Know about Traefik

Let’s Start Putting Everything Together!

Prerequisite

What We’ll Do

Setting Up Traefik Using Helm

Let’s Deploy Some Pods!

Let’s Define a Service!

Ingress

May I Ask For Load Balancing in Action?

Conclusion

Go Further With Traefik!

From Chief Enterprise Architect to Developer

The Good (Tweak), the Bad (Mac), and the Ugly (Terminal)

Step 1 — Homebrew

Done, but Nothing Has Changed

Step 2 — Update Bash to Version 4.4

Configure Bash 4.4 as Your Default Bash

Step 3 — The Colors of Bash

Before

After

Step 4 — Autocomplete Time

Step 5 — May I Ask for a Git Prompt?

What It Looks Like in a Non-Git Directory

What It Looks Like in a Git Directory

Tune It a Bit More

My Pimped Out Terminal

DDD 101 — The 5-Minute Tour

DD What?

So, What Is DDD?

What Sets DDD Apart From Standard OOP?

The Ubiquitous Language

Only What You Understand Can You Explain

Agile Methods Certified

i Shall Not Pass! (Nor Should j or x.)

Health Check — Anemic or Not?

… And Set Boundaries to Keep Them Apart

Is It Time We Talk About Patterns?

But in the End … *This* Is DDD

Further Readings

Kotlin Fun With The Factory Pattern

Ok to have some fun, but … what’s a factory?

The Factory as it is in the GOF

You said it would be fun…

So … are we having fun yet? Just asking.

But if I need a different factory? How can I…

More fun with a fun syntax

Well yeah … why not a factory method in the String itself?

That’s all the fun you’ll get for now

Don’t Use Design Patterns!

The Metaphor Game

If I Were a Pianist

If I Were a Chess Player

No More Metaphors

KISS — Keep It Simple, Stupid.

But if …

REST 101

The HTTP Grammar

And one verb to delete them

**But in the End … This Is DDD**