DEV Community: Tomas Tulka

Learning WebAssembly

Tomas Tulka — Tue, 12 Jan 2021 09:21:49 +0000

A series of learning texts covering the first steps with WebAssembly for complete beginners.

Some time ago I started learning WebAssembly as an absolute beginner. It has been an exciting but not so simple journey.

I decided to publish my continuous and probably neverending notices to make your learning path a little easier.

Here is the actual list of already finished posts. I will constantly update and extend it.

Hello, World of Wasm!

Let’s try WebAssembly for the first time. We will create a simple program in the Wat text format, compile it into Wasm binary, and finally execute it in a browser and as a server application.

Wasm Binary Format

We will explore the structure of the Wasm binary format byte by byte.

Wat Programming Basics

Finally some real programming! We will learn the very basics of the Wat text format, how to work with functions and variables, write conditions, and loops.

Wasm Memory and Working with Strings

The concept of memory objects is very important know-how in Wasm. We will use it to deal with strings.

Running Wasm in the Browser

WebAssembly is part of the web platform, thus it is important to understand interactions between Wasm and JavaScript. We will learn about shared memory and global variables.

Running Wasm in Node.js

Browser is not the only environment that Wasm can run in. We will also learn how to execute Wasm in Node.js, the popular backend platform.

Introducing WASI

WebAssembly System Interface (WASI) provides access to several operating-system-like features from Wasm. We will learn how to write programs that use WASI.

Compiling into Wasm

There are plenty of languages that can be compiled into Wasm. We will take a look at some of them.

AssemblyScript Basics

AssemblyScript syntax is very close to JavaScript and as such is an ideal candidate to write Wasm in. We will explore the basics of AssemblyScript and create a few neat programs.

Image Processing in AssemblyScript

WebAssembly is a great fit for computation-intensive tasks like generating and processing graphics. We will experiment in this field a little.

You are welcome to join me on the exciting journey of learning WebAssembly!

Junior Software Architect

Tomas Tulka — Wed, 16 Dec 2020 15:36:17 +0000

Let me get this straight, software architect is no job title to me, it's a role. A role assigned to one or more persons in the team.

In my experience, the architectural role is taken very naturally by the most experienced or capable developer with great communication skills. Usually, the best ones from us.

Charisma, respect, and natural authority is a good driver for picking up the right person. The role comes with great responsibility and must be accepted by the whole team to succeed.

The hat could be handed over with the time, there could be different architects for different topics or project slices, and so forth.

Are you with me so far? All right, let's move on.

In some (rare) cases, the role can match the job title. For example, the software architect must step out of the team when dealing with outsourcing or open-source community projects.

But I would still expect great programming skills, a lot of experience, and natural authority, right?

Now, let me tell you a true story.

My company hired a new developer. He had almost no experience, poor technical skill, and, worse, no motivation.

I really enjoy working with juniors. They are eager to learn, have plenty of ideas, and brilliant thinking out of the box. Having juniors in the team is always a big benefit (and fun). I advise organizations to hire more of them. All in all, we all used to be juniors once.

This guy was no junior anymore, but hard skills poorer than most of the coding bootcamp graduates. But the worst thing was, he was bullshiting so much!

His constant lying and excuses made each and every coworker boil blood, and our guy was finally fired. With a lot of drama and emotions, of course.

After several months I saw his profile on LinkedIn. He's got a new job as a Software Architect in an international financial institution.

Wow.

Leaving aside the question of how badly the interview process failed, I have to ask how can anyone with such poor technical skills manage this position for more than a few days?

Maybe, the title Software Architect has nothing to do with actual software architecture. It's just somehow good to have this position in an organization that is facing a digital transformation, but there is no actual need for him to do anything useful.

Create a few PowerPoint slides, skitch some generic diagrams, don't bother the development team, and don't argue with the management. You'll be happy, everybody will be happy. Win-win. An instant recipe for success. Cool!

Everyone knows the sad joke about bad managers to be recruited from good programmers. Has the time come for software architects to be recruited from bad developers?

Is a Junior Software Architect a real thing?

Microservices and Bounded Context

Tomas Tulka — Tue, 15 Dec 2020 12:54:48 +0000

Bounded context (DDD) is a good thing to start defining a service boundary with. But practically, it's just too coarse-grained to gain real benefits of microservices.

A service per bounded context means having multiple monoliths. That could be perfectly fine as there's no problem with a monolith. However, with microservices, we want to go further. A bounded context can contain multiple services.

So, what are the right boundaries for services?

I believe it's business capabilities. The fine-grained a business capability can be while still remaining autonomous the small can a service be.

A team per service or a team taking care of multiple services within one bounded context is a good practice. However, a single team should not be working across multiple bounded contexts.

Services should be orthogonal, that is, one service won't affect another.

How do you align your (micro)services?

How much pragmatism is too much?

Tomas Tulka — Mon, 14 Dec 2020 13:21:37 +0000

There are circumstances when one has to "get things done" quickly. It's sad, but it's life.

How much pragmatism is still okay and how much could kill the project in a long term?

I believe, some degree of pragmatism on the lower level of code is just fine. I'm talking about one line of code more or less, one nanosecond more or less, let or const, things like that.

On the other hand, using shortcuts in design is not just pragmatic, it's simply wrong. It creates technical debt that will grow exponentially, hard to fix in the future.

The point is, design (architecture) has an overall impact, while implementation is quite isolated.

Recently, I had a discussion with a software architect, who described himself as pragmatic. As that, he believes the opposite: compromises in design can save a lot of effort, but code must be as clean and efficient as possible.

What are your thoughts?

Good and Bad Monolith

Tomas Tulka — Mon, 14 Dec 2020 07:48:45 +0000

After several years of the microservice hype, it now seems monoliths are cool again! Does it mean, we have learned a lesson?

I guess at least we accepted what Neal Ford stated in his book Building Evolutionary Architectures:

If you can’t build a monolith, what makes you think microservices are the answer?

The disturbing question is: Why is monolith synonymous with a bad design for some and yet the right thing to do for others?

Two Kinds of Monolith

The reason is, there are two different kinds of monolith: physical and logical. While one is mostly a good thing, the other is pure evil.

Physical Monolith

The first kind of monolith is what we usually picture under the word: a physical block of software, typically running as a single process.

A physically monolithic system is developed and built as a single artifact, deployed all at once and falling down in its entirety. Resources such as a database are often shared, communication is local, interprocess.

Monolith

The opposite is then a distributed system composed of multiple physically independent components each running in its own process. Each component owns its resources and communication is performed in a remote manner.

Distributed system

A physical monolith is no anti-pattern, it is a good thing to start with as it is easy to build, deploy, operate, and reason about.

Physically monolithic applications are pretty performant as there are no additional overheads in communication. Cross-cutting aspects are much simpler because no special platform (such as a service mesh) is needed.

As the system gets bigger, further partitioning is possible. A popular option is to apply “satellite” architecture where bottleneck services are separated from the monolithic base.

Monolith with satellites

Logical Monolith

The second kind is a logically monolithic system. Other names used are Big ball of mud, Spaghetti code, etc. Logically monolithic codebases lack boundaries (technologies are not service boundaries!), everything is coupled to everything and no visible architecture is to be found.

Logical monolith

Logical monoliths are evil and dangerous constructs that cause high complexity and tight coupling of building blocks making development expensive and error-prone.

Logically monolithic software is unmaintainable on a scale and exponentially corrodes.

Modular and Distributed Monoliths

By doing things right or very wrong, you will end up with one of two types of systems: modular or distributed monolith, respectively.

Modular Monolith (Modulith)

The opposite of a logical monolith is a modular monolith (or, if you like, modulith). In a modular codebase business capabilities are worked out by services with explicit logical (not necessarily physical) boundaries.

A modular monolith is probably the best architectural approach for most applications. It is easy to extend, maintain, and reason about.

That means, moduliths are really cool!

Modular monolith (modulith)

Although the logical and physical natures of monoliths are independent, they often go hand in hand. That is why people easily confuse them with each other.

As the boundaries in monolithic codebases are typically not physical it is easy to cross them. A monolithic codebase, therefore, requires great discipline.

Distributed Monolith

A logically, but not physically, monolithic system is called a distributed monolith. Distributed monoliths have all the drawbacks of distributed systems with almost none of the benefits.

While dealing with the Big ball of mud is a pain, distributed monoliths are a real disaster.

Distributed monolith

Systems often end up as distributed monoliths while adapting the microservices approach incorrectly.

From Microservices to Monolith

In the last years the microservices movement promised us a lot. The catch is, microservices focus only on physical monoliths, not logical ones.

To understand why we have to take a closer look at what microservices really attempt to solve.

A microservice is a service with some technical additions (independent development cycle). It is important to note the word “technical” — as the logically monolithic design is obviously a logical, not technical, issue, there is nothing microservices could potentially do for us!

Microservices propose a solution to tackle physical monoliths only. That is the reason so many attempts to build microservices failed badly, simply because the wrong issue was addressed and the true problem only got bigger (and, even worse, distributed).

With the logically monolithic design, microservices do not come to the rescue, more the opposite.

Services First

We can think of microservices as a specific approach to Service-oriented architecture (SOA).

There are several definitions of SOA, but we will focus mainly on the concept of a service, because it is the most significant. I use this modified service definition from Udi Dahan:

A service is the autonomous unit of logic for a specific business capability.

Now, it is obvious why microservices as such cannot really help us with the logically monolithic design: monolithically designed microservices are no services at all, they are mere physical components!

Business alone has the key to defining our services correctly. Only well-designed services can tackle logical monoliths and profit from the microservices approach.

It is a hard task, but Domain-driven design can help us a lot!

Conclusion

If you struggle with your monolithic system, the problem may likely lie in its logically monolithic design.

The physical nature of the monolith is usually a secondary problem, easy to solve after the proper service-oriented design has been applied.

Once the logical monolith is resolved, microservices architecture is just one step further...

Types of systems by physical and logical architecture

Originally published on my blog.

Developer On A Job Interview

Tomas Tulka — Fri, 11 Dec 2020 08:11:25 +0000

In the last few months, I was looking for a new job as a software developer.

I attended various interviews, talked to a lot of diverse people, had to solve different tasks, answered plenty of questions, and asked at least as many.

In this post, I will share with you what I have learned, and tell you some useful tips for doing well at your interview to get the job of your dreams.

I won’t give you an exhaustive list of technical questions, brainteasers, and riddles. Instead, I’ll tell you how to make the most sense out of them.

Software Today

Software development nowadays is less about technology and more about people. Good communication skills, knowledge sharing, and team spirit are essential qualities of software professionals in modern organizations. Software becomes more and more a people problem.

Good code is driven by simple, easy-to-understand design with human factors in mind. Perfectly working code is no more enough, as far as it is incomprehensible to other teammates. Great programming skills are not sufficient as far as you’re unable to communicate your work clearly.

This fact has been slowly understood by software companies and the interview process has been adapted accordingly. That is, a flawlessly coded quick-sort algorithm is no guarantee for getting a job offer anymore, and it is actually good.

You spend a great piece of life at work. Not only is it no fun to spend this time with asocial, uncommunicative, or even rude, geeks; it is also pretty unproductive at the same time. Software development became too extensive to fit into a single head entirely, and there are no unicorns. Teamwork is a fundamental prerequisite for a successful (software) product. From experience, just one unsuitable person on a team could cause immeasurable damage to the outcome. I bet you know exactly what I'm talking about.

The extra effort at the interview to ensure you’re a good match for the team means the team is a good fit for you, too.

Soft skills became an important part of your professional profile. Some of them are even more significant than the hard skills you put first in your resume. In fact, any technology can be learned, but it’s really difficult to unlearn being a jerk. Deep knowledge of a particular programming language is not as valuable if you can’t use your potential as a team member to create a great product together. Crucial is the ability and will to learn, communicate, and exchange knowledge with others.

Reputable organizations today are not looking for lone wolves or cowboy developers. Rather, team players and excellent communicators are appreciated.

Tell me about yourself

A few honest sentences about yourself, your background, personal values, and what you are looking for, a nice photo, hobbies and interests are more valuable than an overwhelming list of technologies and programming languages you touched since your studies.

Of course, hard skills are still very important, but your professional profile should tell your potential employer who you are. Forget things like UML or XML, no one is interested, strike off all exotic languages you used to be programming in as a kid, you barely remember them, focus on what’s important and relevant to the position you currently apply for.

Structure your profile hierarchically, start with concepts and then go deeper. Have you designed distributed systems or developed machine learning algorithms? Start with telling that. Continue by diving into concrete technologies, languages, methods. Mention them in the list of working experiences, too. Be consistent and integrous. Focus, structure, remove fluff.

Your professional profile is a sample of your work. Being done poorly tells your potential employer you’re probably no good worker. Your professional profile must be professional.

Sometimes an obligatory question comes up:

Characterize yourself using only three words.

Albeit such a question would fit more to an interview for a job in the marketing department, it’s a good idea to be able to characterize yourself with a few significant properties or values. Open, creative and focusing could be a good try. You can explain those in detail afterward, ideally with some practical examples.

I personally characterize myself with the help of three values I identify with: people, quality and learning. People stands for teamwork, knowledge exchange, trust, and intensive transparent communication not only within the team, but also between teams; quality stands for simplicity, maintainability, product-thinking, and focus on purpose; and finally learning stands for continuous improvement, and exploring new things.

Also, it might be nice to have a life motto that drives your personal characteristics on a very abstract level. Like this one by Albert Einstein: “Everything should be made as simple as possible, but no simpler.”

Personal integrity

It’s easy to make things up. There’s mostly no way how the interviewers could possibly check if all that you say is true. Well, there is a way. We can call it an integrity check.

First, there’s no point in lying. Don’t do that, I mean it. If you make a different person from yourself, that person would be expected to remain as such afterward. But one can’t lie forever. Soon or later, the truth comes up and the consequences are drastic. Losing the job and all the opportunities that you had to cancel due to this one and that could’ve matched your dreams much better. Broken trust, shame, and a black hole in your resume. Definitely not worth it. What’s more, telling the truth is much easier as you don’t have to memorize anything.

Even if everything you say is true, you have to be ready to prove it. You have to watch the integrity of your words. For each and every statement there must be a concrete example from your experience.

You say, you’re creative? Tell me about your best ideas in your previous work. You say, you’re a leader? Tell me a story where you take over a control. Are you good at conflicts resolving? Tell me about a conflict in your team and how you managed to resolve it. You like learning new things? Tell me about a piece of technology you read about recently.

Questions about resolving conflicts and disagreements in the team or on the organization level are very popular among interviewers. They help them to test your integrity as a team player. A true team player welcomes diversity and disagreements. Different opinions are opportunities for exchange, to learn something new, or to refine your own thoughts. Conflicts should never become purely emotional and must be resolved rationally through discourse with the whole team.

As the ability and will to learn is one of the most important characteristics of a good developer, you may expect a lot of questions touching on this aspect:

How do you learn new things? What was the last lecture you attended and what did you learn? How would you explain a particular technology to a younger coworker?

Another interesting sort of questions focuses on legacy software. While, as the old joke says, a new JavaScript framework is born every day, a successful software product could live over ten years. This means most stable companies deal with legacy systems of some kind. A question about how you get on with this is definitely about to come.

While it is good to be keen on shiny new stuff, it’s necessary not to forget about the purpose. You should not adopt a new technology just because of the technology itself, but because it solves a problem you actually have. Microservices or machine learning are cool, but not a silver bullet. You should aim to use good and appropriate technology that fits your context, and communicate it so towards your interviewers.

Be honest with your weaknesses as well. Don’t be afraid to admit that you don’t know everything. It’s perfectly fine to be aware of room for improvements and way better than being caught lying. Much more important is to show the will to learn and to get continuously better.

What, how and why

What and how questions are familiar to every developer. There are plenty of interview questions over the Internet everyone can just print and learn at bedtime as a poem:

How does merge-sort work? What transaction isolation levels do you know? How to check two strings for equality? What does SOLID mean?

I bet you have already been asked all of those questions and you definitely know the correct answers by heart. As this is good, it’s not enough.

Good companies will test your understanding and solving skills rather than encyclopedic knowledge of definitions and algorithms. That is, you should also expect why questions, such as:

Why is bubble sort ineffective and why is it not possible to fix it? In which cases could bubble-sort do make sense? Why is the Repeatable reads isolation level not sufficient to avoid phantom reads? Why do we not use the Serializable level everywhere? Why is the == operator not adequate for checking strings equality in Java? Why does the Dependency inversion principle lead to loosely decoupled code?

Knowing what and how is necessary, but a good engineer must know why, too.

Analyze, be creative

A lot of questions are not meant to be answered directly or even correctly. Many of them have an open ending or no solution at all. Interviewers are interested more in your thought process and solving skills than in a precise answer.

There is no shame in taking some time to think. Nobody expects you to come up with a brilliant solution instantly. Take a deep breath, analyze the question, be creative, and share your thoughts.

What profession would you do if you were not a developer? What is your favorite phone app? What color would you be?

There is no correct answer to the above questions. They all test your creativity and ability to think out of the box. Analyze the hypothetical situation first:

Maybe you always wanted to be a musician and now you have an opportunity to sell your dream. But if you always wanted to be a programmer it’s unlikely that you have a list of alternative professions in mind. Why would you be someone else? Maybe because there is no such job whatsoever! So, what would you likely be in medieval years? Or in a parallel universe where physical laws are not constant and humans communicate via music. Show that you’re not boring. Nobody wants to work with a tedious person.

Some questions are put unclearly on purpose and interviewers expect you to ask additional questions to make the problem clear. Take the interviewers into account as equal partners, try to work it out together, collaborate:

What does “favorite” actually mean? Most beloved or mostly used? What would be the app I would keep if I could keep only one? You can talk about the newest game you had really fun playing, or be practical saying that your favorite app is the internet browser because you can do practically everything with it.

There is no need to study psychology and emotional values hidden under different colors. Your interviewers did certainly not. If you want, say you would like to be blue as it is your favorite color remaining you of the sky. Or maybe yellow like the dress of your child on its first school day. You may also say that you’d like to be white because white is used only little and by only true artists, which means you would participate in as many great paintings as possible. Options are infinite.

You’re supposed to be happy too

The task of an interviewer is to find out if you’re a good fit for the team and the organization she represents. Your task is to figure out if the team and the organization is a good fit for you.

This aspect of the interview is often underrated which can easily lead to disappointment, or even anxiety and burnout. You spend at work way too much time to be unhappy there. If nothing else, please, remember this.

Make sure that the job fits your expectations and there is consistency in what the interviewer offers. Ask questions. A lot of them. Show your interest in the organization, the team, and the product. Ask about company values and check if they match yours. Ask about challenges and how they solve them. Check answers for openness and consistency. I used to ask this very same question to every interviewer:

What is the worst thing about working for the company?

Some companies would promise the earth but the reality turns out to be very different. Do they have concrete examples to share with you? How does the organization support your ambitions and needs? Do they offer lectures and training? Will you have time to experiment and try new things out?

Interviewers often over-use buzzwords they barely understand. Try to address this as well:

What do you understand under Agile? What does DevOps mean to you? How do you do Scrum?

It’s always a good idea to ask about your potential role and organizational structure. An unclear and inconsistent understanding of the role responsibilities, high and opaque hierarchy, or cumbersome processes are signs of a dysfunctional organization.

To show interest brings points for you as well.

How to do your homework

Last but not least is a technical task, usually given as homework with limited time in the first phases of the interview process.

This kind of examination became very popular the last time and replaced typical multiple-choice tests almost completely.

The point is not only to see your skills in action, it’s also a good check of your thinking in an unusual situation.

What is so different about such homework? The conditions are pretty unnatural. It’s no real problem you have to solve. You’re missing context and typically a lot of other information. You might ask additional questions, but you’re also supposed to make assumptions by yourself.

There are several rules I’d recommend:

First, if you’ve got some code to extend, study it. Never do any changes, except you have found a bug or been told otherwise.

Don’t over-engineer. This is time to shine, but it doesn’t mean you should use every piece of technology you know. Rather, make your solution extensible, so it’s open for further improvements. You don’t have to use each design pattern from the GoF catalog, it’s much better to use only one, but properly. Use best practices, but keep it simple. Think in terms of MVP (Minimal Viable Product): What’s the minimal solution it could possibly work?

Always write tests. Not only tests increase your assurance that the code is doing well, but they will also make you more productive and help you get things done quickly. Every change, every requirement and condition must be found in the test suite.

Use static code analysis tools. In this case, the tool that comes along with your IDE will be sufficient. This will be probably the first thing your reviewers will do. Don’t let them find any code smells. It’s easy money.

Consider options, make notes. Your solution will be discussed later, so it’s important to know why you did as you did. There could be more than one right solution, but it’s important to explain why you have chosen this over that. Everything is about trade-offs, you should understand the benefits of your solution and be aware of its drawbacks.

Summary

Let’s summarize the most important points to be aware of when preparing for an interview as a software developer:

Software today is less about technology and more about people.
Working code is no more enough, you have to communicate your work.
Teamwork is a fundamental prerequisite for success.
Ability and will to learn is crucial.
Your personal profile is at least as important as your hard skills.
Be honest, consistent and integrous. Don’t lie.
A good engineer must know why and understand trade-offs.
Analyze, be creative, and share your thoughts.
Ask questions, show interest.
When working on a task, use best practices, but keep it simple.
The job must fit you.

I wish you good luck with the interview, getting your dream job, and having a lot of fun developing software!

Spring Boot Custom Components

Tomas Tulka — Thu, 10 Dec 2020 07:47:43 +0000

Spring Boot philosophy is to develop applications by composing independent, modular and highly configurable components. Spring Boot provides smart and simple mechanisms and conventions for building such components, that could be easily applied in custom projects.

In this post, we will explore those ideas, and show how to create domain-oriented custom components the Spring Boot way.

What Is Spring Boot

Spring Boot takes an opinionated view of the Spring platform and third-party libraries. This means, all necessary dependencies are included and pre-configured, and there is none or very little additional configuration most Spring Boot applications need to add.

Dependencies are consistent with each other and tested in integration.

For web applications, embedded servers (Tomcat, Jetty, Undertow) are included. Even the traditional deployment into an application container is possible, Spring Boot is self-contained as default, everything is included in the final JAR and no additional infrastructure is needed (except JDK, obviously).

In addition, Spring Boot comes with a lot of production ready features, such as loggers, metrics, auditing, tracing, and monitoring.

A simple application skeleton can be easily prototyped by Spring Initializr.

Build Systems

Spring Boot offers Gradle and Maven plugins for packaging and running Spring Boot applications. It is also possible to create and publish Docker images via the plugins.

Gradle

Spring Boot comes with org.springframework.boot and io.spring.dependency-management plugins:

plugins {
  id 'org.springframework.boot' version '2.5.0'
  id 'io.spring.dependency-management' version '1.0.11.RELEASE'
}

Alternatively, only the dependency management could be used in isolation:

plugins {
  id 'io.spring.dependency-management' version '1.0.11.RELEASE'
}

dependencyManagement {
  dependencies {
    dependency 'org.springframework:spring-core:5.3.0'
  }
}

Maven

Typically, your Maven POM file inherits from the spring-boot-starter-parent project:

<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>2.5.0</version>
</parent>

The parent POM brings the Spring Boot plugin, dependency management and other sensible defaults. All default settings can be overwritten in your POM.

Alternatively, only dependency management can be used without the parent POM by using an import scoped dependency:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-dependencies</artifactId>
      <version>2.5.0</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

Features Overview

Spring Boot introduces several features new to the Spring ecosystem.

Spring Boot Application

The SpringApplication class provides a convenient way to bootstrap a Spring application that is started from a main() method.

When the annotation @SpringBootApplication is included on the main class, the application is bootstrapped, auto-configuration enabled and Spring components scan is set to the current package as root.

It is recommended to locate the application class in a root package above other classes. So the package defines the search base for the components scan.

org.example.myshop
+- MyShopApplication
+- catalog
+- delivery
+- order
...

Starters

Starters are a set of convenient dependency descriptors that you can include in your application.

Starters bring all necessary dependencies and configurations into the application:

dependencies {
  implementation 'org.springframework.boot:spring-boot-starter-web'
}

All starters have the core starter spring-boot-starter a direct dependency, which includes auto-configuration support, logging and YAML.

Starters are part of Spring Boot philosophy, a convenient way to include components into your application.

Auto-Configuration

Spring Boot auto-configuration attempts to automatically configure your Spring application based on the jar dependencies that you have added.

When auto-configuration is enabled, components found on the classpath are automatically loaded and configured.

Most standard Spring auto-configurations are highly configurable via properties.

Application Properties

Spring Boot automatically finds and loads application[-profile].(properties|yaml|yml) from the classpath and other default locations.

Properties from the loaded files are added into Spring environment.

Application properties form a configuration structure of a Spring Boot application with default values, which are meant to be overwritten in runtime from the environment or other external sources.

Configuration properties are grouped into trees by the context, typically prefixed by the component name and feature:

# application.yml

spring:
  datasource:
    url: jdbc:postgresql://db:5432/test
    username: admin
    password: secret

Custom Components

Features of Spring Boot can serve as a conventional template for custom components. To do things right, a deeper knowledge of Spring Boot concepts and mechanisms is needed.

In the following section, we take a look at techniques for creating a modular application with independent domain-driven components. The components can be assembled into a single monolithic application or separate applications as microservices afterwards.

For each component a Spring Boot starter with auto-configuration will be created.

Assembling of components into an application is achieved simply by adding the component onto the classpath. Practically, by putting the component starter into the application dependencies.

Spring Boot components are logically defined by auto-configurations, starters are an additional mechanism to bring components into the application conveniently.

Code Structure

We will use Java packages for structuring code by the domain and Maven modules or Gradle sub-projects for technical cuts.

Every component is a self-contained business capability service, exposing multiple artifacts for API and implementation, formed by physical modules.

A typical component source code structure looks like:

delivery/   -- comp. root
+- domain/  -- domain API
+- events/  -- events API
+- jdbc/    -- JDBC impl
+- rest/    -- Restful API
+- spring-boot-starter/ -- starter
+- pom.xml
+- build.gradle
\- settings.gradle

Alternatively, auto-configurations can live in a separate module, which the starter includes as its dependency.

In a single-application scenario a separate module for a Spring Boot application is created on the root level:

myshop/
+- application/
+- catalog/
+- delivery/
+- order/
...

In a microservices scenario, each component has its own application module:

myshop/
+- catalog/
|  +- application/
|  +- domain/
|  +- jdbc/
|  +- rest/
|  \- spring-boot-starter/
+- delivery/
|  +- application/
|  +- domain/
|  +- events/
|  +- jdbc/
|  +- rest/
|  \- spring-boot-starter/
+- order/
|  +- application/
|  +- domain/
|  +- events/
|  +- jdbc/
|  +- rest/
|  \- spring-boot-starter/
...

For both scenarios, the separation of concerns is the structure driver. Every module has its own unique role in the final application.

Starters bring Spring Boot auto-configuration, applications bring Spring Boot application main classes, but all other modules has no Spring Boot concerns or dependencies.

For example, even if the REST module is built upon Spring Web, only the corresponding Spring framework dependency should be included:

// rest/build.gradle

implementation 'org.springframework:spring-web'

The Spring Boot Web starter will be included into the starter module only:

// spring-boot-starter/build.gradle

implementation 'org.springframework.boot:spring-boot-starter-web'

Java Packages

As we build domain-oriented components, packages should be domain-driven as well.

All the modules of a component should share a root package. The modules could be further structured by the domain feature or a technical aspect. Same features should be included in an identical package.

This strategy enables information hiding of implementation classes using Java package accessibility. Consider an example, where ○ and ● mean public and package-protected, respectively:

delivery/
+- domain/
|  \- src/main/java/
|     \- org.example.myshop.delivery
|        \- ○DeliveryService.java
+- events/
|  \- src/main/java/
|     \- org.example.myshop.delivery
|        \- ○DeliveryDispatched.java
+- jdbc/
|  \- src/main/java/
|     \- org.example.myshop.delivery.jdbc
|        \- ●DeliveryServiceJdbc.java
+- rest/
|  \- src/main/java/
|     \- org.example.myshop.delivery.rest
|        \- ●DeliveryRestController.java
\- spring-boot-starter/
   \- src/main/java/
      \- org.example.myshop.delivery
         \- jdbc
            \- ●DeliveryJdbcConfig.java
         \- rest
            \- ●DeliveryRestConfig.java

Classes DeliveryServiceJdbc and DeliveryRestController are in the same package as DeliveryJdbcConfig and DeliveryRestConfig, respectively. This makes them accessible to the configuration classes, which is the only one place they have to be accessible from, and hidden for the rest of the world.

This kind of protection based on the basic language features is a great asset to the overall modularity, preventing the temptation to access implementation details of a foreign component, and violate its sovereignty so.

Custom Spring Boot Starter

A typical Spring Boot starter contains auto-configuration code and declared dependencies, and it’s extensible via configuration properties in a dedicated namespace (prefix).

By convention, the name of a starter starts with the component name followed by -spring-boot-starter suffix:

org.example.myshop:delivery-spring-boot-starter

Auto-Configurations

The entry point to a Spring Boot starter is the META-INF/spring.factories file. Spring Boot checks for the presence of the file within your published JAR. The file should list component auto-configuration classes under the EnableAutoConfiguration key:

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
  org.example.myshop.delivery.DeliveryConfiguration

Auto-configurations must be loaded that way only. Make sure that they are defined in a specific package space and that they are never the target of component scanning.

Under the hood, auto-configuration is implemented with standard @Configuration classes. Multiple configuration classes could be composed via the @Import annotation:

@Configuration
@Import(JdbcDeliveryConfiguration.class)
class DeliveryConfiguration {
  ...
}

The auto-configuration creates and registers all necessary Spring beans for the particular component.

A component starter is the only place configurations should exist. Other modules serve different purposes.

Dependencies

A Spring Boot starter contains all dependencies required by the component as whole.

If, for example, a component has a module with Spring Web restful controllers, the starter should contain the corresponding Spring Boot Starter for web:

implementation 'org.springframework.boot:spring-boot-starter-web'

The minimal dependency every Spring Boot starter must include is Spring Boot core starter:

implementation 'org.springframework.boot:spring-boot-starter'

The component starters are then added as dependencies into the application module:

implementation 'org.example.myshop:catalog-spring-boot-starter'
implementation 'org.example.myshop:delivery-spring-boot-starter'
implementation 'org.example.myshop:order-spring-boot-starter'
...

Configuration Properties

Spring Boot provides an alternative method of working with properties that lets strongly typed beans govern and validate the configuration of your application.

@ConfigurationProperties(
    prefix = "myshop.delivery")
@Setter
@Getter
class DeliveryProperties {

  private String cargoName;
  private String dateFormat;
}

Configuration properties are meant to be a convenient way for initializing auto-configuration:

@Configuration
@EnableConfigurationProperties(
DeliveryProperties.class)
class DeliveryConfiguration {

  @Bean
  DeliveryService deliveryService(
      DeliveryProperties properties
  ) {
    return new DeliveryServiceImpl(
      properties.getCargoName(),
      properties.getDateFormat()
    );
  }
}

The Spring Boot application defines the configuration structure with default values:

# application.yml

myshop:
  delivery:
    cargo-name: PPL
    date-format: yyyy-mm-dd
  order:
    prefix-id: OrderID

Defaults can be overwritten in runtime, for example via environment variables:

MYSHOP_DELIVERY_CARGO_NAME=DHL

Conclusion

Spring Boot is a great tool for developing modular monolithic and microservices applications.

Auto-configurations provide a convenient mechanism for creating independent components in isolation.

Spring Boot starters contain configurations and dependencies for components and define configuration structure via configuration properties with dedicated namespaces.

A Spring Boot application assemblies the components and provides cross-cutting concerns in addition.

Example

An example code of a rich modular Spring Boot application can be found on my GitHub.

Links

Originally published on my blog.

You Aren’t Gonna Need Microservices

Tomas Tulka — Wed, 09 Dec 2020 14:42:40 +0000

You Aren’t Gonna Need It (YAGNI) is one of the most important principles in software development.

Perfection is achieved not when there is nothing more to add, but when there is nothing more to take away. ~ Antoine de Saint-Exupery

You can see YAGNI as a special case of the Keep It Simple Stupid (KISS) principle. YAGNI applies to a higher level as it tells us to cut off any unnecessary part while KISS advises making the rest as simple as possible.

Everything should be made as simple as possible, but no simpler. ~ Albert Einstein

Violation of YAGNI is sometimes called overengineering. A feature for every possible case, functions/methods with a lot of input parameters, multiple if-else branches, rich and detailed interfaces, all those could be a smell of overengineering. It’s the opposite of the famous UNIX-mantra: Do one thing well.

To avoid this trap, always ask yourself a question: “Is it really needed right now?” If the answer is “Well, maybe” then probably not.

Often, significant architectural decisions must be made to implement a feature. This is a problem because the earlier a decision is made the less information we have and the more likely a wrong decision is to be made. Therefore, it is a good practice to defer difficult decisions until the last possible moment. Ignoring YAGNI leads to a violation of this practice.

The main point of YAGNI is to pay the costs first when the feature is actually needed, and not right now, just in case. YAGNI violations make development always expensive because the complexity behind each feature must be paid, even though the feature is not necessary (yet). In other words, accidental complexity rises. And complexity is expensive. Complexity is no fun.

The same reasoning can be applied to microservices. But, don’t take me wrong: there are plenty of highly useful benefits that the microservices style can bring you and a lot of great principles you can apply even to your monolith. However, the actual question remains the same: Do you really need them right now? Do you really need to scale every service up to a thousand instances? Do you need a Kubernetes cluster, Kafka stream-processing platform, and Istio service mesh? Once again: maybe, but probably not right now.

Fallacies of microservices

Let's take a look at some typical fallacies I've observed so far among teams adopting microservices:

Microservices help you find boundaries

This is probably the most dangerous misunderstanding of microservices and a very expensive mistake you can make. Remember: Microservices are about technology, boundaries are about business. No technology can help you define your boundaries, only proper understanding of your business does.

Microservices are just one option for how to physically separate components once boundaries are correctly defined. At the same time, they make the boundaries hard to change if they are found to be wrong, which often happens, especially in the early phases of product development.

Try to define your service boundaries without any concerns of technology, build a team around them, implement a few product iterations. As you gain some confidence, you can turn them into microservices, if it will solve an actual problem.

Microservices make your system modular

Microservices don't make your system modular out of the box. Modularity means logical separation of business concepts. Microservices make this separation visible and difficult to cross over. While this is good, it does not come without drawbacks such as resistance to refactoring the structure of the modules.

Anyway, there are much cheaper options such as using packages/namespaces, modules/artifacts, etc. Those solutions provide a good level of physical separation along with ease to change.

Microservices make your system performant

The possibility to scale every single service independently is one of the most emphasized advantages of microservices. While this is true, it comes with costs. Running every service as a separate process can't be done without supporting infrastructure. Things like service mesh, service discovery, or load balancer come to mind first.

Cloud providers offer a working solution for you, but one has to bear in mind that remote calls are always more expensive than inter-process communication. Do you really need to scale all your services? Maybe one or two most loaded would be enough. Vertical scaling or scaling the whole system are options that usually just work and that are much cheaper than microservices.

Another aspect is good modularity. When service boundaries are incorrectly defined and multiple remote calls must be done to process a request, the overall performance is likely to decrease when turning such a system into microservices.

Microservices are cheaper to operate

A typical example of this fallacy is Serverless computing. While there definitely are use-cases where the serverless approach can be beneficial and cheap to develop and operate, the amount of such use-cases is pretty limited. What's more, it's easy to get an impression that going serverless means just writing code and taking no care of how it's being operated. This is usually not true. For example, monitoring is still an important and hard problem no one else will solve for you.

Serverless is an extreme case. An application running in the cloud in the same way as previously in your own server warehouse is likely to be much more expensive. This is very true, especially for so-called Lift&Shift solutions.

One idea behind microservices is to move a piece of complexity from development into operations, where it is easier (and cheaper) to tackle. Yes, by doing microservices right, you might save some money on development but your operation costs will probably increase rapidly. This is not necessarily a bad thing as you do save some bucks at the end of the day, it's just something to be aware of.

Microservices are easier to develop

Because a lot of complexity is moved to operations, great Ops skills are required inside the teams when taking the microservices-oriented approach. As the need for communication between Devs and Ops becomes crucible, there's no room for traditional separation by technical responsibilities. All members of the team must work together on a whole business feature, preferably colocated in the same room.

Microservices are a practical approach to Agile development and require a real DevOps mindset, where the whole team is responsible for the product from the first sketches to running the production environment.

If "DevOps" in your organization is done by that guy sitting in the last office on the second floor, then you shouldn't even think about microservices.

Microservices are small

Very popular topic and a big misconception. "Micro" does mean small or even smaller, right? Small is good, small is easy. Easy to understand, easy to develop, easy to operate… Well, no. "Micro" is not about size, it is about responsibility. Anecdotes such as two pizza teams or code that fits on my screen might work in some organizations, however, they are no general rules.

A service should be minimal in its responsibility and API. A service should implement just a single business capability. Nothing more, nothing less. The contract must be simple and clear. No unnecessary pollution, no implementation details.

The implementation can be big, even huge at the beginning. The bounded context (from Domain-driven development) defines the biggest possible service. That is the boundary to start with. Other services will emerge by themselves as the domain becomes clearer.

Summary

Always ask yourself: "Do I really need this right now? Is this the simplest thing that can possibly work?"

Don't go microservices just because they look cool and everybody is talking about them - they are no silver bullet. Doing so would be a violation of the YAGNI principle on the architecture level. That is, don't do it.

All in all, you aren't gonna need it!

Originally published on my blog.

How Cohesion and Coupling Correlate

Tomas Tulka — Wed, 09 Dec 2020 08:27:15 +0000

As I was finishing my blog post about defining service boundaries, I had a very strong feeling that there must be some abstract concept of what I was trying to explain using actual examples…

Of course, there is! It is the concept of cohesion and coupling that I will discuss in this post.

I will start with some definitions:

Cohesion is the degree to which the elements inside a module belong together.
Coupling is the degree of interdependence between software modules.

High cohesion and loose coupling are the most important principles in software engineering. They manifest themselves everywhere from code to team organization.

Cohesion and coupling are tightly related. Why are they so important? Both help us reduce complexity, the true fun killer of software development.

To a lot of people, sadly, the concepts sound too academic and are therefore often poorly understood.

What is cohesion, anyway?

Tough question. The definition is pretty broad and there are several interpretations out there. Not all of them are necessarily wrong, the more valid question is: which one is most beneficial? I use the following definition as I believe it always leads to cohesive components with tight coupling inside and loose coupling outside, which is exactly what we want:

The degree of cohesion of a component by a particular key equals the number of elements cohesive by the key within the component divided by the sum of the total number of elements cohesive by the key in the whole system and the number of elements not cohesive by the key inside the component.

This long definition can be expressed as a simple formula:

The cohesion formula

Where c stands for the component, k stands for the key, and N stands for the number of elements. Obviously, the maximal cohesion of a component is equal to one. This is what we strive for.

I want to emphasize that cohesion does not depend on the number of connections between elements, which is what coupling is all about. Cohesion is more about belonging together. However, cohesive components do tend to have a higher degree of coupling within the component, but that is just a symptom of high cohesion, not the cause.

The definition above might look complicated, but it is actually quite easy. It can be illustrated by some examples. We measure the degree of cohesion by the violet key for the components bordered with a dashed line in the following systems:

Example measurements of cohesion

Functionality (business) is always the right key to use. Violet and blue can stand for sales and accounting, a product and an invoice, or user registration and ordering.

My definition may be a bit oversimplified as the boundaries are not always as solid and obvious. This is why business experts must be involved.

Myth busted

Cohesion and coupling are almost always discussed together as they tightly correlate. The relation is sometimes a source of confusion as well, although its understanding is very useful to gain the utmost for the software system under development.

A typical myth, I often hear people believe in, puts cohesion and coupling in opposition. Practically, they say that “the higher the cohesion the tighter the coupling”. I will show you how wrong this statement is.

This is usually illustrated with an example: Consider the highest possible cohesion of the system where every module is represented by a single line of code (or a single function, an object with a single method, etc.). Such a degree of cohesion will inevitably increase the coupling between modules to the maximum.

As the conclusion is true, there is a small problem in the prerequisite. To discover it, we must recall the definition of cohesion once again. It talks about belonging together, the strength of relationship of elements, and a common purpose.

What does it mean in practice? In fact, splitting elements that belong together actually makes cohesion lower. So, in the example above, the system really does not have the highest possible cohesion, just the opposite: breaking modules into the smallest possible elements will separate related concepts and will lead to pretty low cohesion.

The moral here is: Cohesion is not something you can create automatically. Cohesion is discovered in a particular context. That is why it is so hard for cohesion to be reliably measured. We will discuss this in detail later, stay tuned.

Cohesion and coupling

Let me show you some pictures. In each figure below, there are the very same elements with the very same dependencies. Those are further differently organized. Related domain concepts are represented with the same color:

Low cohesion, tight coupling

Elements in the first picture have no explicit boundaries; they are an example of so-called coincidental cohesion. Such architecture is known as the Big Ball of Mud or the God Object (in OOP code).

High cohesion, tight coupling

The second picture shows a system with three modules and a lot of dependencies between them. Although the modules are highly cohesive, they are cohesive by the wrong key. This happens when code is organized by other than a domain relationship. A typical example is a logical organization of code in the Layered Architecture: just imagine modules such as controllers, repositories, services, etc. Have you seen these already somewhere? Hell yeah!

High cohesion, loose coupling

The system in the third picture shows the ideal scenario: correctly organized modules leading to high cohesion and loose coupling. The right key for organization is functionality, in other words, a business domain. The domain defines abstractions with a stable purpose the cohesion is driven upon. By the way, that is the main idea of the Domain-Driven Design.

Focus on cohesion, not coupling

We have exhausted all variants except one: a system with low cohesion and loose coupling. Is it even possible to have such architecture? Unfortunately, it is, and it is actually pretty common.

Systems with low cohesion and loose coupling are the result of incorrect understanding of the domain and applying purely technical approaches to decouple the modules in an arbitrary way. Interfaces everywhere with no abstraction representing a domain purpose are typical for systems built in this way.

Misuse of interfaces will not actually reduce coupling anyway, it just moves it into the runtime.

Striving for loose coupling at any cost can (and will) harm cohesion. As loose coupling is driven by high cohesion, we should strive for high cohesion in the first place.

Level of abstraction

Yes, high cohesion does not only make the system easy to understand and change, it also reduces the level of coupling.

How is this even possible? Common sense says that the dependencies do not disappear simply by reorganizing elements. While this is true for the overall system dependencies, high cohesion does reduce dependencies on a higher level of abstraction.

That is, although the absolute amount of dependencies remains the same, the coupling is tackled on different levels of abstraction.

The whole is greater than the sum of the parts. ~ Aristotle

Indeed, we can ignore the interdependencies inside modules and thus get a simplified big picture with only three loosely coupled elements:

Coupling on the higher level of abstraction is dramatically reduced

Neat. As we see, high cohesion actually results in loose coupling!

Talk to me in code!

Pictures are nice, but as software developers, we trust only code, don’t we? Alright, I have some code for you. Consider a simple class for a Book Store (in JavaScript, whatever):

class BookStore {
  add(book) { … }
  remove(book) { … }
  sale(book) { … }
  receiptFor(book) { … }
}

This class does literally everything. Its cohesion is pretty low and all clients, whatever their needs are, will be coupled to it. It is an example of a God Object. We can do better:

class Inventory {
  add(book) { … }
  remove(book) { … }
}

class Sales {
  sale(book) { … }
  receiptFor(book) { … }
}

The Inventory class looks fine, but what about Sales? Must sales and accounting really be so tightly related? Maybe it would be better to split the functionalities into more cohesive classes:

class Sales {
  sale(book) { … }
}

class Accounting {
  receiptFor(book) { … }
}

But what if our Book Store is just a small family business with one clerk handling sales together with accounting on one old cash desk? We have just hit the nail on the head: we cannot really know what the right cohesion key is unless we know the domain really well. True cohesion is defined by the clients. High cohesion is achieved when there is no way to split the module any further while still satisfying the needs of the client. By the way, this is exactly what the Single Responsibility Principle teaches us.

Conclusion

High cohesion and loose coupling are the main design drivers towards simple system architecture, which is easy to understand, change, and maintain. High cohesion and loose coupling help us reduce accidental complexity and create modules with well-defined boundaries.

Coupling is about connections, cohesion is about belonging together.
Cohesion cannot be created automatically; instead it is discovered in a context.
Cohesion is defined by the clients.
True cohesion is domain-driven.
High cohesion results in loose coupling.
High cohesion is to die for. It enables all others, loose coupling included.

Originally published on my blog.