Having successfully reimplemented our e-commerce website www.otto.de in a highly decentralised, agile project approach, we currently face the challenge of establishing an agile mindset outside the cosy cheese dome of a well-protected and well-specified project. During this project we felt like living on a separate planet. Business and technology work entwined, scope was managed by ourselves, we had the liberty to change and adapt our processes and methodologies, introduced an agile management framework, implemented Scrum, built autonomous and cross-functional product development teams and closed feed-back loops with continuous integration and delivery. Or putting it a different way: we learned how to change into a learning matrix organisation. This process was thrilling, demanding to all of us and we are proud of having mastered this challenge. After leaving our project “Lhotse” behind and literally lifting our project cheese dome, we are now facing an urge to change management culture and improve our capability in inter-organisational collaboration.  

When we began the development of our new Online Shop otto.de, we chose a distributed, vertical-style architecture at an early stage of the process. Our experience with our previous system showed us that a monolithic architecture does not satisfy the constantly emerging requirements. Growing volumes of data, increasing loads and the need to scale the organization, all of these forced us to rethink our approach.

Therefore, this article will describe the solution that we chose, and explain the reasons behind our choice.

In this blog you will find a lot of information on how we implement code for our shop in the best way. But in some cases we also buy commercial standard software, for instance for components which give us a faster time to market or which cannot be implemented by us in a better or more cost effective way.

Another reason to buy software is data exchange with external systems using standard interfaces when there are products on the market which have already implemented those interfaces.

Additionally, we want to improve experience in using software as a service (SAAS).

In the past months some of my team members and me had several workshops with different vendors to find commercial software components for some parts of our ecommerce platform. Independently from concrete products and vendors, we made some good and some not so good experiences in presentations held by vendors to help us find what we need. And that is what we want to share in this article.

So, read this carefully if you are a software vendor 😉

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.