Published on Aug 19, 2016
Recorded at SpringOne Platform 2016.
“It is not necessary to change. Survival is not mandatory.” -W. Edwards Deming
Work takes time to flow through an organization and ultimately be deployed to production where it captures value. It’s critical to reduce time-to-production. Software – for many organizations and industries – is a competitive advantage. Organizations break their larger software ambitions into smaller, independently deployable, feature -centric batches of work – microservices. In order to reduce the round-trip between stations of work, organizations collapse or consolidate as much of them as possible and automate the rest; developers and operations beget “devops,” cloud-based services and platforms (like Cloud Foundry) automate operations work and break down the need for ITIL tickets and change management boards. But velocity, for velocity’s sake, is dangerous. Microservices invite architectural complexity that few are prepared to address. In this talk, we’ll look at how high performance organizations like Ticketmaster, Alibaba, and Netflix make short work of that complexity with Spring Boot and Spring Cloud.
Node.js makes building web applications and APIs easy – Google App Engine makes running node.js in production fun. Walk through deploying a Hello World app, using the gcloud npm module to talk to other Google Cloud services, and using the Cloud Vision API to analyze images.
Jimmy Bogard / Chief Architect at Headspring
The greenfield project started out so promising. Instead of devolving into big ball of mud, the team decided to apply domain-driven design principles. Ubiquitous language, proper boundaries, encapsulation, it all made sense.
But along the way, something went completely and utterly wrong. It started with arguments on the proper way of implementing aggregates and entities. Arguments began over project and folder structure. Someone read a blog post that repositories are evil, and ORMs the devil incarnate. Another read that relational databases are last century, we need to store everything as a stream of events. Then came the actor model and frameworks that sounded like someone clearing their throat. Instead of a nice, clean architecture, the team chased the next new approach without ever actually shipping anything.
Beyond the endless technical arguments it causes, domain-driven design can actually produce great software. We have to look past the hype into the true value of DDD, what it can bring to our organizations and how it can enable us to build quality systems. With the advent of microservices, DDD is more important than ever – but only if we can get to the good parts.
Recorded at SpringOne Platform 2016.
Speaker: Agim Emruli
Spring Cloud allows to implement cloud native application across different cloud platforms. Spring Cloud has also a dedicated support for running applications on the Amazon Web Service platform. This talk will introduce common patterns and best-practices to run the application the AWS cloud and how to use the platform provided services efficiently.
Senior Developer, Atlassian
QA Engineer, Atlassian
As you migrate your applications toward microservice architectures, new pains start to appear – like testing, for example. How on Earth do you verify all these separate moving parts work together before releasing? How can you be sure that your code is compatible with services that can’t easily be spun up anymore? They are all written in different languages, operated by separate teams and deploy every day!
Do you find yourself lying awake at night missing monolithic applications where integrations were easier to test? In this talk we’ll reveal how Atlassian is adopting a new strategy called “contract testing”, using the Pact open source library to test our microservices. We’ll introduce the concept of contract testing, talk about why we love this approach, and go through some examples and patterns that will help you get started.
Microservices are associated with extreme isolation (e.g. no shared database, autonomous dev-ops teams, etc.) At its best, this creates a practical boundary within which modeling and design have a chance to thrive. In Domain-driven Design (DDD) we call this a “Bounded Context”. Bounded contexts take many forms, some leakier than others, and the current best practices of microservices have given us perhaps the strongest mainstream manifestation of this principle to date. In this way, microservices can help teams who attempting DDD or other sophisticated approaches.Yet, as services get small and numerous, we might substitute one problem for another: The tangle of the monolith just migrates to become a tangle of interactions between microservices. Here, the strategic design principles of DDD can give architects a conceptual framework for working with suites of services and higher-level relationships between larger parts of systems.
This talk will introduce a few strategic design concepts and explain how they apply to development of microservices, as a tool for teams trying to grow large systems more coherently.
INVEST – Definition
The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story. If the story fails to meet one of these criteria, the team may want to reword it, or even consider a rewrite (which often translates into physically tearing up the old story card and writing a new one).
A good user story should be:
- “I” ndependent (of all others)
- “N” egotiable (not a specific contract for features)
- “V” aluable (or vertical)
- “E” stimable (to a good approximation)
- “S” mall (so as to fit within an iteration)
- “T” estable (in principle, even if there isn’t a test for it yet)
- 2003: the INVEST cheklist for quickly evaluating user stories originates in an article by Bill Wake, which also repurposed the acronym SMART (Specific, Measurable, Achievable, Relevant, Time-boxed) for tasks resulting from the technical decomposition of user stories.
- 2004: the INVEST acronym is among the techniques recommended in Mike Cohn’s “User Stories applied“, which discusses it at length in Chapter 2.