The ancient Greek poet Archilochus wrote that “the fox knows many things, but the hedgehog knows one big thing.” In social psychology, these terms have been used as a shorthand for describing two cognitive styles: foxes, who are comfortable with nuance, can live with contradictions, and have different strategies for solving different problems, and hedgehogs, who focus on the big picture, reduce every problem to one organizing principle, and solve problems through that singular lens. ...

All healthy technology discussions should begin with business goals and use those goals as a reasonable set of guidelines to focus technology investment decisions. These business goals are best articulated from a deep understanding of what the company, the product team, or the marketing team want to accomplish. In a business-first model, technology is forced to balance the desires for technical effectiveness and efficiency with the operational needs of the business. This balance can be difficult to achieve if you’ve ended up in a leadership position from a technology background — you are used to solving problems by writing code and it becomes difficult to think of other ways to solve them! ...

In creating a development workflow for releasing HTTP+JSON APIs, many teams settle on the API description and documentation standard OpenAPI. A natural conversation that takes place after settling on OpenAPI is whether or not you should develop your API using a “design-first” method or a “code-first” method. I believe that narrowing the discussion to these two extremes overly simplifies the discussion. Instead, I prefer to talk about API development as a continuum of development process that revolve around the prominence of the API description document in the process. ...

One of the recurring themes of any technology discussion is programming language. It doesn’t take much effort to find blog posts with dramatic headlines (and even more dramatic comments) about how shipping a new project with Haskell or Clojure or Elm improved someones job, marriage, and life. These success stories are posted by raving fans that have nothing but the best to say about their language of choice. A common thread running through these posts is that they are typically tied to building out new, greenfield projects. I can’t help but wonder. After the honeymoon of building a new project with a new programming language, what happens next? Is it all bubble gum and roses? ...

Spring Data REST combines the features of Spring Data with Spring HATEOAS to make it easy to build hypermedia-driven REST APIs on top of Spring Data repositories. The basic functionality provided out of the box creates and exposes simple REST endpoints for performing CRUD operations on Spring Data repositories. For a lot of use cases, this is entirely enough functionality to meet your needs. In other cases, you need to extend the REST API to include additional functionality that isn’t provided by Spring Data REST and it can be difficult to determine exactly how to do this. In this blog post, I show you how to augment a Spring Data REST API with additional endpoints to turn a basic CRUD API into a full featured web service. ...

Microservices have become part of the software engineering cultural zeitgeist to the extent that alternative approaches to architecture and development are treated as somehow inferior. Given the challenges that running microservices present, I usually recommend beginning development of new projects and systems as a single deployable unit — the monolith. Sam Newman, in the book “Building Microservices”, agrees with this approach. He recommends leveraging microservices only if you can become convinced of the benefits for your system, not as a default for every project. ...

When building and running a system deployed as a monolith, we are able to make a certain set of assumptions about the behaviour of the overall application. One of the biggest assumptions we make is that the memory space for the application all resides on the same machine. With this model, function and library calls can assume that their view of the data structures for the application are accurate, and that you can retrieve or mutate that data immediately and deterministically (leaving the thornier issues of multi-threaded applications aside for a minute). These assumptions allow teams of programmers to work effectively and efficiently across multiple packages, libraries, classes and functions. ...

In a shopping cart, the swivel wheels of the cart are set in the front, and the fixed wheels are set in the back. Now picture yourself pushing a shopping cart backwards. Almost naturally, you swivel the cart to move the front end to one side or the other before beginning to push the cart. Now picture yourself pushing a shopping cart backwards, on an ice rink. Here, the cart keeps sliding around even after you’ve stopped pushing it. Instead of going straight from one end of the rink to the other, the cart makes giant S-shaped turns. ...

In The Cathedral and the Bazaar, Eric Raymond recounts the early years of Linux. Specifically questioning how the “part-time hacking of several thousands of developers scattered all over the planet” could create perhaps the most complex, functioning application in history. How could a “babbling bazaar of differing agendas and approaches” coalesce into a coherent and stable system without some form of centralized planning? The fact that this bazaar style seemed to work, and work well, came as a distinct shock. As I learned my way around, I worked hard not just at individual projects, but also at trying to understand why the Linux world not only didn’t fly apart in confusion but seemed to go from strength to strength at a speed barely imaginable to cathedral-builders. ...

Many organizations have multiple applications that are being built independently as a microservices-based platform. By its nature, a microservice platform is a distributed system running on multiple processes or services, across multiple servers or hosts. Building a successful platform on top of microservices requires integrating these disparate services and systems to produce a unified set of functionality. It is naïve to think that we can only choose one communication style to solve all problems; if integration needs were always the same, there would be only one style and we would all be happy with it. In reality, a single service can can communicate using many different styles, each one targeting a different scenario and goals. This challenge is what brings me to the topic of this blog post: when and why do we use different communication standards? ...