Am 21. August kündigt Jeff Barr mal eben in einem Blogpost an, dass der neue T3-Instanztyp für EC2 nun in 12 AWS-Regionen verfügbar sei ^[1]. Durch die cosee-Büros geht ein kurzer Aufschrei der Begeisterung. Denn nach signifikanten Performance-Verlusten auf T2-Instanzen durch Meltdown/Spectre Patches zum Anfang des Jahres ist ein neuer credit-basierter Instanztyp auf einer aktuellen CPU-Architektur schon lange überfällig.

Wieso überhaupt T-Instanzen einsetzen?

Betreibt man eine Microservice Architektur auf AWS (die den Schritt zu Kubernetes noch nicht gegangen ist), so kann dank horizontaler Skalierung selbst die kleinste general-purpose Instanz (m5.large) schon mal zu überdimensioniert sein, um einen Service zu hosten. Einige Microservices sind überhaupt nur an einem kleinen Teil der Anfragen beteiligt und verursachen dadurch über den Tag verteilt kaum zweistellige CPU-Auslastung. Gleichzeitig sollen sie aber über genug Headroom verfügen, um mit der Lastspitze umzugehen, wenn beispielsweise mal eben 1000 neue Produkte dem Shop hinzugefügt werden. Ähnlich verhält es sich bei Dev- und Staging-Umgebungen, die die meiste Zeit des Tages brach liegen, aber dennoch in der Lage sein sollen, kurzzeitig Production-ähnliche Last zu verarbeiten. Weiterlesen →

Wir coseeaner arbeiten schon lange in den unterschiedlichsten Formen agil. Dabei ist in unseren Teams besonders der Scrum-Ansatz stark vertreten. Um uns im Sinne der Agilität immer weiter zu entwickeln, sind unsere Scrum Master, Führungskräfte, Tinkas und Entwickler immer wieder auf der Suche nach spannenden Austausch- und Weiterbildungsmöglichkeiten. So kommt es, dass wir uns immer wieder auf den verschiedensten Veranstaltungen herumtreiben. Die Meetups von Intrinsify.me, der agile Stammtisch Mainz/Wiesbaden, das Scrum Master Gathering und diverse Konferenzen sind dabei nur einige Beispiele. Unser Wissensdurst ist trotzdem nicht gestillt! Darum haben wir beschlossen den ScrumTisch Darmstadt ins Leben zu rufen. Weiterlesen →

Bereits zum dritten Mal fanden Ende Juni die ContainerDays in Hamburg statt. Nachdem einige coseeaner bereits 2017 begeistert und mehr als motiviert von den ContainerDays zurückgekommen waren, war uns schnell klar, dass wir auch in diesem Jahr die Konferenz entern wollten. Also machten wir uns am Montagnachmittag mit fünf Wolkenarchitekten auf den Weg nach Hamburg, um unseren Wissenshunger auf alles in der Docker- und Kuberneteswelt zu stillen. Weiterlesen →

Seit Anfang Mai ist es nun offiziell: Wir sind „APN Standard Partner“ von Amazon Web Services! Damit sind wir, neben der Software AG, der zweite AWS Partner mit Sitz in Darmstadt. Wie kam es dazu und warum haben wir das auf uns genommen?
Weiterlesen →

Nach der Ankündigung einer Managed Kubernetes Lösung auf der re:Invent Ende 2017 hat das lange Warten seit letzter Woche ein Ende. EKS [1] wird generell verfügbar und kann allgemein genutzt werden, wenn auch die EU-Regionen vorerst außen vor sind. Wir wollen uns kurz anschauen, was EKS uns nun wirklich abnimmt und um welche Bereiche man sich selbst kümmern muss.

Es gibt unzählige Möglichkeiten, einen Kubernetes-Cluster selbst zu betreiben. Angefangen beim manuellen Aufsetzen auf die harte Tour [2] über CLI-Tools kube-adm, kops oder andere kommerzielle Angebote kann man aus einer Vielzahl von Möglichkeiten auswählen. Mit EKS (Elastic Kubernetes Service) nimmt AWS uns das Aufsetzen und den Betrieb der Master Nodes ab, inklusive HA-Unterstützung und Integration mit AWS-Diensten.

Andere Public-Cloud-Anbieter stellen mit Google Kubernetes Engine (GKE) und Azure Kubernetes Service (AKS) bereits fertige Managed Kubernetes Angebote zur Verfügung. EKS fällt hier aber ein wenig aus der Reihe. Anders als bei GKE und AKS hat man bei EKS nur die Minion-Instanzen in Form einer oder mehrerer AutoScaling Groups unter Kontrolle. Die Master werden von EKS verwaltet, d.h. Themen, wie Updates, Hochverfügbarkeit und Skalierung können wir delegieren.

Weiterlesen →

The z-index CSS property specifies the z-order of a positioned element and its descendants. When elements overlap, z-order determines which one covers the other. An element with a larger z-index generally covers an element with a lower one.

— z-index by MDN

Working with z-index values in large projects can be really difficult. On a growing project, you can observe the z-index values increasing. At some point it is not uncommon to see values like 99999999. If you want to add a new component with a custom z-index it is hard to test all affected components and its impact. Worst case scenario, you have to go through multiple files and compare z-indices, then build and test again and so on. This can be really frustrating because you end up adding or removing a digit to an already unnecessary high value. This way of handling z-index values leads to many bugs such as components that falsely overlay other components. We encountered the same problem in one of our projects and discovered that a lot of bugs were caused by conflicts between z-index values.

Weiterlesen →

Vor einigen Wochen saßen die unterschiedlichen Teams bei cosee zusammen, um den Bedarf an Entwicklern in den verschiedenen Aufgabengebieten zu besprechen. Neben möglichen Verschiebungen innerhalb der Teams wurde schnell klar, dass neue Kollegen durchaus benötigt werden. Neben den bereits genutzten Veranstaltungen, um mögliche Bewerber auf uns aufmerksam zu machen, wie beispielsweise dem Software Engineering Projekt der TU Darmstadt oder den regelmäßigen TechTalks, entbrannte eine Diskussion über weitere Möglichkeiten.

Wir hatten die Idee, einen Tag der offenen Tür für Studenten anzubieten. Dies ermöglicht es einerseits den Studenten, einen Einblick in ein modernes, agil arbeitendes Unternehmen zu gewinnen, und uns, unsere Arbeitsweise jungen und interessierten Studenten nahe zu bringen und mögliche Bewerber schon im Alltag, außerhalb einer Bewerbungssituation kennenzulernen.

Weiterlesen →

Seit geraumer Zeit gibt es bei uns Brettspielabende. Weil ich selbst sehr begeisterter Brettspielfan bin, habe ich zu einem Neujahrs-Kick-Off mal eine Auswahl von Spielen mitgebracht. Den Kollegen hat das gemeinsame Spiel an diesem Abend sehr viel Spaß gemacht – man hat eine gemeinsame Aktivität abseits der Tastatur und lernt Kollegen aus anderen Teams besser kennen. In der folgenden Unternehmensretrospektive kam deshalb der Wunsch auf, einen regelmäßigen Spieleabend zu initiieren.

Seither finden sich nach jeder ersten Retro im Monat Leute zum Spielen zusammen. Mal spielen alle zusammen ein Spiel, wie etwa im August Captain Sonar, mal teilen wir uns zu kleineren Grüppchen auf (zum Thema „kooperative Spiele“ etwa kamen Robinson Crusoe und Space Alert parallel auf den Tisch). Meist beherrscht ein Thema den Abend; vor allem auch deswegen, weil dadurch die Spielauswahl einfacher wird. Der Begriff „Thema“ ist dabei weit gefasst:

• Es kann thematisch im engeren Sinne in den Weltraum oder zu den Wikingern gehen.

• Thema kann aber auch ein Mechanismus (Warteschlangenmanipulationsspiele, Stichkartenspiele, etc.) oder

  

• ein aktuelles Event wie die Bekanntgabe der „Spiel des Jahres“-Nominierungen sein.

Wir hatten auch schon Besuch von Brettspiel-Podcastern (Grüße an die Brettagogen und die Bretterburg). Das größte Event in der Brettspielszene war natürlich die letzte Woche zu Ende gegangene SPIEL – die Internationalen Spieltage in Essen. Im Nachgang der Messe wird es bei uns zum wiederholten Mal eine Nachbereitung der Messe geben, auf der diejenigen, die auf der Messe waren, von ihren Eindrücken berichten und ihre Beutestücke zeigen können. Es werden Spieleautoren, Rezensenten, Blogger und jede Menge Spielbegeisterte mit von der Partie sein. Alle, die nicht auf der Messe sein konnten, bekommen so (hoffentlich) einen Eindruck von der Atmosphäre und dem Flair der Veranstaltung; und nicht zu vergessen frischen Spielnachschub.

Mittlerweile trifft sich die ein oder andere Runde auch mal „außer der Reihe“ etwa für eine Runde Descent oder bald Gloomhaven.

So bringen Gesellschaftsspiele auch bei uns Leute zusammen, helfen Team-übergreifend mit allen in der Firma in Kontakt zu bleiben und vor allem gemeinsam Spaß zu haben.

Es fühlt sich völlig natürlich an: Technologieentscheidungen werden von den Entwicklern in den Teams getroffen – nicht durch den CTO oder einen übergeordneten Architekten. Die Entwickler in den selbstorganisierten Teams kennen die zu lösenden Probleme am besten und haben meist auch einen guten Überblick über die möglichen technischen Lösungen. Nach einigen Wochen aber entsteht Streit: Jeder will mitreden. Die Entwickler sind nicht immer alle einer Meinung. Wie viele Standards brauchen wir für alle Teams? Ein Praxisbericht über sinnvolle Rahmenbedingungen für Technologieentscheidungen in selbstorganisierten Teams.

Weiterlesen →

Die Software Technology Group der TU Darmstadt bietet jedes Jahr im Wintersemester das Software Engineering Projekt an. Dabei wird Firmen die Möglichkeit gegeben, Projekte an studentische Gruppen zu vergeben und so potenzielle neue Mitarbeiter kennen zu lernen. Studenten bietet es eine Abwechslung zum theoretischen Studienalltag, indem sie in einer realen Aufgabe praktische Erfahrung sammeln können. cosee nimmt seit einigen Jahren daran Teil. Aus einem der Projekte möchte ich einen Erfahrungsbericht geben.

Weiterlesen →