Aktuelle E-Commerce-Systeme bestehen häufig aus mehreren Servern, die mit dem Browser der Benutzer über SSL-gesicherte Leitungen kommunizieren. Allerdings sind die Rechner der Kunden nicht die einzigen, mit denen ein Shop Daten austauschen muss: fast immer ist es notwendig, dass die einzelnen Server des Systems auch untereinander kommunizieren müssen. Dabei ist es unerheblich, ob es sich um eine Microservice– oder eine Vertikalen-Architektur handelt. Sogar die in die Tage gekommenen Monolithen nutzen bei einem Multi-Tier-Ansatz gerne mehrere Server.

Gemein ist diesen Backend-Requests (im Gegensatz zu dem Netzwerkverkehr zwischen Kunden-Browser und otto.de), dass hier im Allgemeinen keine vertraulichen Daten über die Leitung gehen, sondern beispielsweise die Aktualisierung einer Produktverfügbarkeit oder Konfigurations-Requests. Diese Inhalte müssen also nicht geheim gehalten werden, was uns den Aufwand und die Komplexität erspart, sie zu verschlüsseln.

Trotzdem darf natürlich nicht jeder die Texte im Shop ändern oder Produktinformationen anpassen, daher benötigen wir eine Methode zur Authentifizierung und Autorisierung der Requests.

Scaling Agile @ OTTO – Learning at Scale: Agilität als umfassende organisatorische Herausforderung
von Peter Wolter und Stephan Kraus

Was ist eigentlich das Ziel hinter Agilität? Geschwindigkeit und Veränderungsfähigkeit! Die Grundlage dafür sind entsprechende Strukturen und Rahmenbedingungen im Unternehmen und die Fähigkeit der Organisation zu lernen: Kleine, autonome, interdisziplinäre Teams, die eigenständig und in hoher Verantwortung auf die unternehmerischen Ziele hinarbeiten, die entscheiden, was getan wird. In einer unsicheren Welt von sich schnell ändernden Anforderungen müssen diese Teams lernen. Dazu muss es eine lernende Kultur geben, um das Wie ständig anpassen zu können. In der lernenden Kultur ermächtigen wir Menschen, kreativ zu werden und ihren eigenen Weg zu finden. Dafür beschreiben wir vor allem das Warum.

In der Ausgabe 04/2016 des OBJEKTspektrum haben wir zum Schwerpunktthema „Führung und Management in der IT“ einen Artikel veröffentlicht, in dem wir unseren Weg zu einer lernenden Organisation beschreiben.

Whenever we present how we release features and deploy our code in one of OTTOs core functional teams, we are met with a certain set of questions, e.g..: “Why do you want to deploy more than once a week?”, “If you automate release and test management, what are the release and test managers doing?”, “How can we prevent major bugs to enter the shop?”, “Where is the final control instance to decide if something goes live?”, or the typical question “Who is responsible if something breaks?” or simply “Why the heck would someone want to do this?”

Let us answer those questions. Let us guide you through our way of working. Let us show you what processes we have (and which ones we do not have) and give you a hint on how to increase productivity and quality at the same time (without firing the test manager). All you have to do is to sit back, relax and let go of your concerns to lose control. Don’t worry, you won’t lose it.

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.  

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

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.

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?