Agile borrowed from the JIT manufacturing processes originally at Toyota. The Agile Manifesto itself summarized the key aspects brought into programming from JIT.

Original Agile processes like eXtreme Programming (XP) brought breathtaking speed of delivery to a waterfall world. But Agile has not stood still. From XP’s original (and aggressive) 2­3 week iterations, we now see individual programmers pushing new functionality to live systems several times a day!

Acceleration drives changes to an organization’s processes and skills, just as the original shift to Agile from waterfall. Organizations reluctant to address such changes, however, inhibit the acceleration. Indeed, their attempts to accelerate often result in lower morale and flawed delivery; these failures drive conservative (and destructive) attitudes against change.

In this talk, we will address a myriad of drivers for faster delivery:

• Available technologies, including Cloud, languages, and new frameworks
• Shift toward active monitoring rather than one­time acceptance testing
• Refined, lighter processes consistent with shorter cycles
• Architecture that is fault­-tolerant rather than provably perfect
• Shift toward trying ideas rather than firm requirements
• Reduction in role specialists
• Reduction in delivery team size

For each of these drivers, we will describe teams that have taken these steps and the corresponding accelerated delivery.

MicroService Architectures has debuted on the ThoughtWorks Technology Radar as the first technology they address, and with strong recommendations to immediately experiment. In this talk, we will outline the guidelines we have used at two different companies to implement MicroServices. And more importantly, we will tell you about the pitfalls we have encountered.

MicroService Architectures has debuted on the ThoughtWorks Technology Radar as the first technology they address, and with strong recommendations to immediately experiment. In this talk, we will outline the guidelines we have used at two different companies to implement MicroServices. And more importantly, we will tell you about the pitfalls we have encountered.

MicroService Architectures has debuted on the ThoughtWorks Technology Radar as the first technology they address, and with strong recommendations to immediately experiment. In this talk, we will outline the guidelines we have used at two different companies to implement MicroServices. And more importantly, we will tell you about the pitfalls we have encountered.

The Agile movement shifted the relationship between clients and developers in a profound way. In waterfall processes, clients specified large amounts of functionality, then nervously faded into the background until the fateful day-of-delivery. With Agile, developers strove to engage with clients continuously, and delivered much more frequently against their needs. A new trust was established. At the Forward Internet Group in London, we are implementing a second major shift between clients and developers. The trust of the clients in developers evolves into a broader trust of the developers to deliver business value without resorting to a series of well-defined stories. In essence, the business has empowered the developers to do what they think is right for the business. This model, popularized by Facebook, has several labels, but the one we prefer for our flavor is Programmer Anarchy.

The Agile movement shifted the relationship between clients and developers in a profound way. In waterfall processes, clients specified large amounts of functionality, then nervously faded into the background until the fateful day-of-delivery. With Agile, developers strove to engage with clients continuously, and delivered much more frequently against their needs. A new trust was established. At the Forward Internet Group in London, we are implementing a second major shift between clients and developers. The trust of the clients in developers evolves into a broader trust of the developers to deliver business value without resorting to a series of well-defined stories. In essence, the business has empowered the developers to do what they think is right for the business. This model, popularized by Facebook, has several labels, but the one we prefer for our flavor is Programmer Anarchy.

The Agile movement shifted the relationship between clients and developers in a profound way. In waterfall processes, clients specified large amounts of functionality, then nervously faded into the background until the fateful day-of-delivery. With Agile, developers strove to engage with clients continuously, and delivered much more frequently against their needs. A new trust was established. At the Forward Internet Group in London, we are implementing a second major shift between clients and developers. The trust of the clients in developers evolves into a broader trust of the developers to deliver business value without resorting to a series of well-defined stories. In essence, the business has empowered the developers to do what they think is right for the business. This model, popularized by Facebook, has several labels, but the one we prefer for our flavor is Programmer Anarchy.

Hands-on development of asynchronous micro-services using a bus architecture.

While “micro-services” is becoming a heavily over-worked term, it has been interpreted many ways. In this hands-on workshop, we will explore a particular style, tiny asynchronous services, that was the core of one of the most successful implementations. Given an animated specification of flow, we will embark on delivering the proposed services, wrestling with the issues common to this new paradigm. Participants have a choice of languages, with new starting code in Java, C#, and Ruby. At the end of the workshop, we will discuss MicroServices challenges and organizations that are optimized for such architectures.

IoT, the prevalence of specialized interconnected devices, has invaded business and home. The myriad of devices, hubs, and APIs has created a Tower of Babel that makes the Android phone scene seem mild. Such devices are inherently less network ­reliable than previous products, primarily due to the casual attachment (convenient outlets). Add to this heterogeneous soup the security exposure that has already been exploited in DDoS attacks, and you have an environment begging for technical solutions.

We propose Asynchronous MicroServices as a solution. Borrowing a page from historical J2ME thinking and more recent implementations using IFTTT, we introduce small bridging MicroServices for the various devices. Further, also consistent with MicroServices, we keep these services very simple: They broadcast device status to an event bus, or listen for action commands to relay to the devices from the same bus. Interaction among the various IoT devices is delegated to yet another set of MicroServices.

One exemplary composite application would accept signals from motion detectors to turn on appropriate lights, or alternatively alerting the owner of unauthorized intrusion. Using the same motion detectors, lights can be dimmed and eventually turned off. Room temperatures and even audio/video gear could be adjusted as well. Using Asynchronous MicroServices, we can also set up controlled access from the outside world, rather than exposing each device with its own vulnerabilities.

Finally, we wrap up talking about the challenges of implementing this in my own flat using Hue lights, Amazon Alexa, and 4th generation Apple TV. We run these MicroServices in local containers attached to the same home network. Docker support of ARM devices enables low-cost redundancy as well.

RESERVE YOUR SEAT NOW

While “micro-services” is becoming a heavily over-worked term, it has been interpreted many ways. In this hands-on workshop we will explore a particular style, tiny asynchronous services, that was the core of one of the most successful implementations.

WHAT WILL I LEARN

Given an animated specification of flow, we will embark on delivering the proposed services, wrestling with the issues common to this new paradigm. Participants have a choice of languages, with new starting code in Java, C#, and Ruby. At the end of the workshop, we will discuss MicroServices challenges and organizations that are optimized for such architectures.

RESERVE YOUR SEAT NOW

IoT, the prevalence of specialized interconnected devices, has invaded business and home. The myriad of devices, hubs, and APIs has created a Tower of Babel that makes the Android phone scene seem mild. Such devices are inherently less network ­reliable than previous products, primarily due to the casual attachment (convenient outlets). Add to this heterogeneous soup the security exposure that has already been exploited in DDoS attacks, and you have an environment begging for technical solutions.

We propose Asynchronous MicroServices as a solution. Borrowing a page from historical J2ME thinking and more recent implementations using IFTTT, we introduce small bridging MicroServices for the various devices. Further, also consistent with MicroServices, we keep these services very simple: They broadcast device status to an event bus, or listen for action commands to relay to the devices from the same bus. Interaction among the various IoT devices is delegated to yet another set of MicroServices.

One exemplary composite application would accept signals from motion detectors to turn on appropriate lights, or alternatively alerting the owner of unauthorized intrusion. Using the same motion detectors, lights can be dimmed and eventually turned off. Room temperatures and even audio/video gear could be adjusted as well. Using Asynchronous MicroServices, we can also set up controlled access from the outside world, rather than exposing each device with its own vulnerabilities.

Finally we wrap up talking about the challenges of implementing this in my own flat using Hue lights, Amazon Alexa, and 4th generation Apple TV. We run these MicroServices in local containers attached to the same home network. Docker support of ARM devices enables low cost redundancy as well.

IoT, the prevalence of specialized interconnected devices, has invaded business and home. The myriad of devices, hubs, and APIs has created a Tower of Babel that makes the Android phone scene seem mild. Such devices are inherently less network ­reliable than previous products, primarily due to the casual attachment (convenient outlets). Add to this heterogeneous soup the security exposure that has already been exploited in DDoS attacks, and you have an environment begging for technical solutions.

We propose Asynchronous MicroServices as a solution. Borrowing a page from historical J2ME thinking and more recent implementations using IFTTT, we introduce small bridging MicroServices for the various devices. Further, also consistent with MicroServices, we keep these services very simple: They broadcast device status to an event bus, or listen for action commands to relay to the devices from the same bus. Interaction among the various IoT devices is delegated to yet another set of MicroServices.

One exemplary composite application would accept signals from motion detectors to turn on appropriate lights, or alternatively alerting the owner of unauthorized intrusion. Using the same motion detectors, lights can be dimmed and eventually turned off. Room temperatures and even audio/video gear could be adjusted as well. Using Asynchronous MicroServices, we can also set up controlled access from the outside world, rather than exposing each device with its own vulnerabilities.

Finally we wrap up talking about the challenges of implementing this in my own flat using Hue lights, Amazon Alexa, and 4th generation Apple TV. We run these MicroServices in local containers attached to the same home network. Docker support of ARM devices enables low cost redundancy as well.

MicroService Architectures has debuted on the ThoughtWorks Technology Radar as the first technology they address, and with strong recommendations to immediately experiment. In this talk, we discuss the challenges we have faced at three different companies in implementing MicroServices (successfully!), and the different ways we addressed the challenges.

A common theme runs through conferences, whether focused on MicroServices, DevOps, Lean Startup, or a myriad of other popular topics: Enabling an organization to Go Faster . I explore the need to go faster (which is hardly new), and three areas inhibitors arise: Technology choices, staid business Processes, and traditional Organization structures and roles. For each, I cite personal experiences in overcoming each.

It is one thing to talk about MicroServices. It is another altogether to have to build them.

After a brief introduction of MicroService principles, we will watch an animation of a MicroService environment. We will start with a pre-built skeleton microservice environment (message bus plus a couple of RESTful services running against it). We will then design and implement additional services to broaden the overall functionality. These additional services can be written in any language that will run on the participants laptop. While pairing is strongly encouraged, it is not required.

In the final stage, different pairs will implement different services, yet they will all run together implementing the animation.

We wrap up with the participants making observations on what they learned (and how it may be different from MicroServices they are currently implementing, if any).