Building Better Software Faster

@aahoogendoorn | www.ditisagile.nlBuilding better software faster 1

@aahoogendoorn | www.ditisagile.nl

Buildingbettersoftwarefaster

Sander Hoogendoornditisagile.nl


Sander Hoogendoorn

MeDad, software architect, agile coach, programmer, trainer, speaker, writerBooks, articles, conferences, courses

WorkOwner ditisagile.nlCTO ANVAFormer CTO insurance companyFormer global agile thoughtleader Capgemini

Webwww.sanderhoogendoorn.comaahoogendoornaahoogendoorn [email protected]



As a project managerI would like to demo untested code so I embarrass myself



The Times They Are a-Changin'


Moore’s LawThe number of transistors in a dense integrated circuit doubles approximately every two years.






The Times They Are a-Changin'On our block





Too much, too soon Hard to deliver, harder to test, impossible to maintain






Dependencies will kill you



MicroservicesA definition


MicroservicesIn short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.

These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized managementof these services, which may be written in different programming languages and use different data storage technologies.

Martin Fowler




From the trenchesMicroservices in real life


For the things we have to learn before we can do them, we learn by doing them

Aristotle



Microservices require an evolutionary software architecture



Some guidingprinciplesBusiness processes first


We implement business processesWe move towards a systems landscape consisting of micro-applications and micro-componentsRequirements are modeled (in smart use cases)Micro-applications implement a single elementary business processMicro-applications and micro-components all have their own bounded contextMicro-applications do not have storage, and only talk to other micro-applications and micro-componentsMicro-components have their own storage (in MongoDB), and only talk to other micro-componentsCommunication uses a simple open protocol – JSON on REST We avoid transactions as much as possible

Some guiding principles


Smart use cases


Presentation

Process

Domain

Services

Outside world

PagesGrids, Panels, Controls

Use casesFlow

Factories, RepositoriesEntities, Enums, Value objects

Gateways

ComponentsRelations Dossiers Intermediaries Accounts Rates


Service interface

Process

Domain

Data / Services

Outside world

ResourcesRepresentations

Use casesFlow

Factories, RepositoriesEntities, Enums, Value objects

Gateways

StorageRelations Dossiers Intermediaries MongoDB



Designing microservicesModular design and bounded contexts


Doing big up-front design is dumb, doing no design up-front is even dumber

Dave Thomas


Bounded contexts


Single responsibility principleGroup together things that change togetherSeparate things that change for different reason


Bounded contextWhen you model larger domains, it becomes progressively harder to create this single unified model. Instead of creating a single unified model, you create several, all valid within their bounded context


The single unified domain modelOr more often the humongous data model

Product

Vendor

Stock

Order

Client

Delivery

Payment


Bounded contexts

Product

Vendor

Stock

Order

Client

Delivery

Payment

Product




Testing microservicesFailing fast


Fail fast, fail often, fail forward


Manual tests

Scenario tests

Integration tests

Unit tests


Manual tests

Scenario tests

API tests

Unittests


A development lifecycleWhat to test?

Code Developer Test Test Integration

TestAcceptance

Test LivePrepareand Design

DevelopersUnit tests

DevelopersPeer review

TestersScenario’sAnd API’s

TestersScenario’sand API’s

Product ownerProduct


Even though you might have really brilliant testers…

ExploratoryTesting,anyone?



Deploying microservicesContinuous integrationand build pipelines


How often do you deploy to production?


A typical build pipeline


TestAcceptance

Test LivePrepare and Design


ProductionAcceptanceIntegrationTestDevelopment

A typical build pipelineTraditional (virtual) infrastructure


TestAcceptance



ProductionProvisionedProvisionedProvisionedDevelopment

A typical build pipelineProvisioned infrastructure (on the fly)


TestAcceptance



Microservices Building multiple deployment pipelines

Code Developer Test Test Acceptance

Test Acceptance Live








Infrastructure as code



AgilebeyondScrumTowards continuously delivering software


Lowering our fences


Dogmagile


The red sprint anti-pattern


Minimal viable productsThink small, deploy early and frequently


Do we need this

NOW?


Roadmaps over plansWhile there is value in the items on the right, we value the items on the left more



Continuous delivery An approach in which teams ensure that every change to the system is releasable, and that we can release any version at the push of a button.

Aimed to make releases boring, so we can deliver frequently and get fast feedback on what users care about.Jez Humble



In retrospectiveSome final thoughts


The times are a-changin’How are we going to keep up?

Towardsmicro-applications and microservices

Modelingrequirements

Focus oncore

technologies

Continuousdelivery

Minimal viableproducts

Rationalizeour legacy

Domain driven design

Leveragethe cloud




References and questions

www.sanderhoogendoorn.com

www.ditisagile.nl

aahoogendoorn

aahoogendoorn

[email protected]