Abstract

In the last two months, we started our journey towards a new microservices architecture. Among other things, we found that our existing CD tools were not ready to scale with new requirements. So we tried a new approach, defining our pipelines in code using LambdaCD. In combination with a Mesos cluster we can deploy new applications after a few minutes to see how they fit into our architecture by running tests against existing services.

Part 1: The underlying infrastructure
Part 2: Microservices and continuous integration
Part 3: Current architecture and vision for the future

Abstract

In the last two months, we started our journey towards a new microservices architecture. Among other things, we found that our existing CD tools were not ready to scale with new requirements. So we tried a new approach, defining our pipelines in code using LambdaCD. In combination with a Mesos cluster we can deploy new applications after a few minutes to see how they fit into our architecture by running tests against existing services.

Part 1: The underlying infrastructure
Part 2: Microservices and continuous integration
Part 3: Current architecture and vision for the future

In this part of my article I want to explain how we define microservices and why we think they are the best choice for our applications. Furthermore I will give you a brief introduction outlining which problems we have with common CI tools and how we want to solve them with LambdaCD.

A little more than a year ago, things at work were completely different for me than they are now. I was a Java programmer working on a big, monolithic piece of software. There was also some JavaScript for frontend and MongoDB, some Groovy for scripting Gradle and the occasional Bash script, but if you had called me a 100% Java programmer, I would not have objected. Don’t get me wrong, I enjoyed my job and I always loved to work with Java but as you may relate to, after years of hacking Java, I was a little tired of it. As you may also relate to, I had little hope for the situation to change significantly anytime soon. As it turned out, I was wrong about that. Hugely wrong.

Abstract

In the last two months, we started our journey towards a new microservices architecture. Among other things, we found that our existing CD tools were not ready to scale with those new requirements. So we tried a new approach, defining our pipelines in code using LambdaCD. In combination with a Mesos cluster we can deploy new applications after a few minutes to see how they fit into our architecture by running tests against existing services.

Part 1: The underlying infrastructure
Part 2: Microservices and continuous integration
Part 3: Current architecture and vision for the future

Als ich im August 2012 meine Ausbildung zum Fachinformatiker bei OTTO begann, startete ich hoch motiviert und mit ebenso hohen Erwartungen in die Ausbildung. Doch durch eine Berufsschule, welche außer Unterrichtsausfall, festgefahrenen Lehrern und einem Rahmenlehrplan von 1997 nichts zu bieten hat, ließ das Motivationstief leider nicht lange auf sich warten.

Damit stellte ich keinen Einzelfall dar, was folgende Fragen aufruft: Wie kompensiert man die Wissenskluft zwischen veraltetem Rahmenlehrplan und einer sich immer schneller entwickelten IT-Welt? Wie kann man das Potential einer E-driven-Company nutzen um zukünftigen IT-Azubis eine individuelle, verantwortungsvolle und zeitgemäße Ausbildung zu bieten?

On March 6th, we hosted the Varnish Developer Day VDD at our Loft 6. We are proud to give the community a place to meet and to support the open source project Varnish.

Why do we do this?
Varnish is one of the main software products we have integrated into otto.de to make our shop fast and to achieve our business goals. Keeping in mind that we have a ’shared nothing‘ software architecture, we need at least one central system where everything comes together. How should each of our independent applications receive HTTP requests? A reverse proxy fulfills this role naturally.

Abstract: „Der Trend zu Microservices in komplexen Systemumgebungen ist die architektonische Antwort auf agile Softwareentwicklung und Continuous Delivery. Kleine Systeme, die unabhängig voneinander entwickelt und separat betrieben werden können – eine Architektur als Enabler für das Business. Den Vorteilen gegenüber stehen aber die klassischen Herausforderungen der Integration. Wie sehen Integrationstests aus, wie kann der übergreifende Betrieb sichergestellt werden und wie werden fachliche Abhängigkeiten behandelt? In diesem Vortrag werde ich anhand der neuen E-Commerce Plattform von OTTO aufzeigen, wie wir den Monolithen Otto.de in vertikale Systeme aufgeteilt und dadurch ein agiles Arbeitsumfeld ermöglicht haben. Besonders für die organisatorischen Konsequenzen werde ich Lösungsansätze mit ihren Vor- und Nachteilen vorstellen. Klassische Querschnittsaspekte wie Tracking, Performance und Security haben wir in die Architektur integriert und diese damit im Laufe der Zeit kontinuierlich weiterentwickelt.“

Die MicroXchg Konferenz am 12./13. Feb. 2015 in Berlin war die erste exklusive Konferenz zum Thema Microservices. In zwei parallelen Tracks gab es verschiedene Vorträge zum Thema Microservices – national und international, aus Anwender- und Beraterperspektive, von Microservice-Pionieren und Kritikern. Dieser Artikel fasst die wesentlichen Aussagen meines Vortrags zusammen und reflektiert die Reise der Otto.de Architektur von einem klassischen Monolithen zu einer verteilten Architektur mit Microservices.

Gibt es etwas zwischen Microservices und monolithischen Architekturen? Die Antwort lautet natürlich: JA. Aber warum?

Recently we released tesla-microservice to github. It is a software written in clojure and it is the basis of some of the microservices we are working on as part of the technical platform of otto.de. We named our software after Nikola Tesla an ingenious engineer and inventor of the late 19th and early 20th century.

tesla-microservice is based on the component library, an elegant and quite minimal framework to build stateful applications in clojure.

Currently tesla-microservice allows you to build a basic web application with some basic features:

  • Load config from classpath and/or filesystem.
  • Aggregate a status based on the status of the different components and their subcomponents.
  • Deliver status details as json.
  • Serve a simple healthcheck based on that status.
  • Report to graphite using the metrics library.
  • Manage routes using compojure.
  • Serve content with an embedded jetty.