Showing 9 out of 9 results


Software Technologies that Stand the Test of Time

What software technologies have stood the test of time or have had a massive influence over existing systems? Which do you love or hate? We asked these questions to the GOTO Book Club authors and interviewers that made up the lineup for the second season. Find out what Nicki Watt, CTO/CEO at OpenCredo, Eberhard Wolff, fellow at innoQ, Venkat Subramaniam, founder of Agile Developer, Inc., Liz Rice, chief open source officer at Isovalent, Rebecca Nugent, professor in statistics & data science, Phil Winder, CEO of Winder Research, Hanna Prinz, DevOps & software engineer and Eoin Woods, CTO at Endava, had to say. The conversation was moderated by Rebecca Parsons, CTO at ThoughtWorks.

May 6, 2021

Getting Started with Service Mesh

Hanna Prinz, a consultant at InnoQ, and Eberhard Wolff, fellow at InnoQ, the authors of Service Mesh Primer explain what a service mesh is and more importantly when and if you should use it. They also delve into the main features and reasons for deciding to use one.

November 20, 2020

Martin Fowler and Sam Newman: When to Use Microservices (And When Not To!)

Upgrade your microservices knowledge by listening to a spirited conversation between two living legends: Sam Newman and Martin Fowler

September 3, 2020

Practical Microservices

With the increasing maturity of container technology and orchestration tools like Kubernetes, transitioning from legacy monolithic applications to microservices is becoming more accessible to teams and organizations around the world. We will be looking at what it practically means to make this move, and what patterns and tools are needed to make it successful.


The Programmer’s Swiss Army Knife - Engineering Tools @ Prezi

Every software company has their own toolbox for building features for their users. This talk provides a deep dive into the tools, processes, and documents that engineers utilise for their everyday work to deliver valuable, lovable, and usable products to their customers. You will also get a peek into the history of Prezi’s infrastructure, what the challenges were when we were migrating from a monolith to microservices. All of this will be demonstrated through the lifecycle of a complex feature.


From Monoliths Through Cloud Native to Software Supply Chains

In the recent years we have experienced dramatic changes in the complexity of our software. Those changes pushed the industry to adjust the development culture towards DevOps, lead to popularisation of containers and explosion of microservices. But are those independent events or parts of a bigger plan for the software industry transformation? I would argue, the letter! In this talk I'll start from the past and draw the possible line into the future. This will include a bit of philosophy and a lot of diagrams to explain the changes in technology and in the ways we create software.


The Big Friendly Monolith

Everybody seems to be doing microservices these days. And for good reasons: it’s an architecture style that allows scalability and maintainability – it’s a great fit for a DevOps organization. But it’s not so easy to get to this promised land. If you already have a monolith, you may find that it’s very difficult to chop it up into microservices. But on the other hand, starting with microservices in a greenfield entails substantial investment of time setting up and learning microservices stuff – during which you’re not producing any business value. Domain Driven Design (DDD) and Command Query Responsibility Segregation (CQRS) are known to provide us with means to tackle complexity within an application. However, they also provide us with patterns and guidelines to manage the complexity of large scale, distributed environments. If we apply them consistently, they enable us to write a friendly, structured monolith that can be transformed into a microservices landscape in a controlled manner. In this talk, we’ll zoom in on this DDD/CQRS approach to microservices. We’ll introduce Axon Framework as a practical way of doing this in Java. We’ll focus on the messaging between microservices in the distributed case. We will discuss different approaches to ensure decoupling of services on the API level, but also ensuring flexibility to change the system's behavior at runtime simply by switching services on and off."


Modular Monoliths

If you want evidence that the software development industry is susceptible to fashion, just go and take a look at all of the hype around microservices. It's everywhere! For some people microservices is "the next big thing", whereas for others it's simply a lightweight evolution of the big service-oriented architectures that we saw 10 years ago "done right". Microservices is by no means a silver bullet though, and the design thinking required to create a good microservices architecture is the same as that needed to create a well structured monolith. And this begs the question that if you can’t build a well-structured monolith, what makes you think microservices is the answer? **Prerequisite attendee experience level:** professional


Serverless is the Abstraction We Deserve

Monolithic applications are an anti-pattern, especially when moving to cloud scale deployments. For years, microservices adoption has been tied to containers and more recently to Kubernetes. But moving from pure software development to learning Kubernetes and all of the amazing tools and components in that ecosystem is daunting. YAML just doesn't make a great user interface. While we have been building platforms on platforms, this thing called Serverless has become a real thing. Of course, it has a platform underneath, but it's abstracted away. Serverless lowers the barrier to entry, allowing developers to seemingly leapfrog over the complexity and burden of learning containers and launching a Kubernetes practice. Developers focus more on their core business logic, and less on all of the things around it. However, beyond the first few functions things can get complicated. Triaging issues and analyzing performance can be nigh impossible. The abstraction can become a liability. But Serverless exists to address a real problem, and it's the abstraction we have to work with. In this session, we'll discuss how we get past the initial adoption of Serverless to fully embracing it, taking on a "Serverless First" strategy. This talk is from our partner.