Martin Fowler's Blog, page 33

Microservices Resource Guide

I've put together a resource guide for microservices: a page
that selects and organizes information about microservices. I
don't intend it to be a comprehensive listing, but rather my
selection of articles, videos, and podcasts that provides the
best compilation of material on the topic. The links cover what
they are, when to use them, how to build them, and who has used
them. If you're looking for more information on these topics,
this should give you a solid starting point.

Bliki: DevOpsCulture

Agile software development has broken down some of the silos
between requirements analysis, testing and development. Deployment,
operations and maintenance are other activities which have suffered a similar
separation from the rest of the software development process. The
DevOps movement is aimed at removing these silos and encouraging
collaboration between development and operations.

DevOps has become possible largely due to a combination of new
operations tools and established agile engineering
practices [1], but these are not enough to
realize the benefits of DevOps. Even with the best
tools, DevOps is just another buzzword if you don't have the
right culture.

The primary characteristic of DevOps culture is increased collaboration
between the roles of development and operations. There are some important
cultural shifts, within teams and at an organizational level, that support
this collaboration.

An attitude of shared responsibility is an aspect of
DevOps culture that encourages closer collaboration. It’s easy for a
development team to become disinterested in the operation and
maintenance of a system if it is handed over to another team to look
after. If a development team shares the responsibility of looking
after a system over the course of its lifetime, they are able to
share the operations staff’s pain and so identify ways to simplify
deployment and maintenance (e.g. by automating deployments and
improving logging). They may also gain additional
ObservedRequirements from monitoring the system in
production. When operations staff share responsibility of a system’s
business goals, they are able to work more closely with developers
to better understand the operational needs of a system and help meet
these. In practice, collaboration often begins with an increased
awareness from developers of operational concerns (such as
deployment and monitoring) and the adoption of new automation tools
and practices by operations staff.

Some organizational shifts are required to support a culture of
shared responsibilities. There should be no silos between
development and operations. Handover periods and documentation are a
poor substitute for working together on a solution from the start.
It is helpful to adjust resourcing structures to allow operations
staff to get involved with teams early. Having the developers and
operations staff co-located will help them to work together.
Handovers and sign-offs discourage people from sharing
responsibility and contributes to a culture of blame. Instead,
developers and operations staff should both be responsible for the
successes and failures of a system. DevOps culture blurs the line
between the roles of developer and operations staff and may
eventually eliminate the distinction. One common anti-pattern when
introducing DevOps to an organization is to assign someone the
role of 'DevOps' or to call a team a 'DevOps team'. Doing so
perpetuates the kinds of silos that DevOps aims to break down and
prevents DevOps culture and practices from spreading and being
adopted by the wider organization.

Another valuable organizational shift is to support autonomous
teams. In order to collaborate effectively, developers and
operations staff need to be able to make decisions and apply changes
without convoluted decision making processes. This involves trusting
teams, changing the way risk is managed and creating an environment that is free
of a fear of failure. For example, a team that has to produce a list
of changes for sign-off in order to deploy to a testing environment
is likely to be delayed frequently. Instead of requiring such a manual
check, it is possible to rely on version control, which is fully auditable.
Changes in version control can even be linked to tickets in the team's
project management tool. Without the manual sign-off, the team can
automate their deployments and speed up their testing cycle.

One effect of a shift towards DevOps culture is that it becomes
easier to put new code in production. This necessitates some further
cultural changes. In order to ensure that changes in production are
sound, the team needs to value building quality into the development
process. This includes cross-functional concerns such as performance
and security. The techniques of ContinuousDelivery, including
SelfTestingCode, form a basis which allows regular, low-risk
deployments.

It is also important for the team to value feedback, in
order to continuously improve the way in which developers and
operations staff work together as well as the system itself.
Production monitoring is a helpful feedback loop for diagnosing
issues and spotting potential improvements.

Automation is a cornerstone of the DevOps movement and
facilitates collaboration. Automating tasks such as testing,
configuration and deployment frees people up to focus on other
valuable activities and reduces the chance of human error. A helpful
side effect of automation is that automated scripts and tests serve
as useful, always up-to-date documentation of the system. Automating
server configuration, for example, removes the guesswork associated
with a SnowflakeServer and means that developers and
operations staff are equally able to know and change how a server
is configured.

Notes

1:
Operations tools include virtualization, cloud computing and automated
configuration management. These are often supported by engineering practices such as Continuous Integration,
evolutionary design and clean code.

Share:


if you found this article useful, please share it. I appreciate the feedback and encouragement

Third installment of Refactoring Loops to Collection Pipelines

In this third installment, I show an example of making sense
of a loop that marks preferred offerings from a list.

Microservice Trade Offs

Many development teams have found the microservices architectural
style to be a superior approach to a monolithic
architecture. But other teams have found them to be a
productivity-sapping burden. Like any architectural style,
microservices bring costs and benefits. To make a sensible
choice you have to understand these and apply them to your
specific context.

Second installment of Refactoring Loops to Collection Pipelines

In this second installment, I show an example of refactoring
a simple nested loop.

Refactoring Loops to Collection Pipelines

I've long been a fan of the programming pattern that I call
the collection
pipeline. This allows me to write computation on collections
in the form of a pipeline of familiar operations (eg filter,
map, reduce). More and more language environments now have the
language features and collection APIs to support pipelines, but
since they have been limited in use for so long, more people are
familiar with loops. In this article (which I'm releasing in
installments) I'll take some loops and show how I'd refactor
them into collection pipelines.

photostream 86

Le Puch, Languedoc, France

A Cherry Picker's Guide to Doctor Who

Recently I got chatting with a friend who was toying with
trying out the TV series "Doctor Who", but was put off by its
long history and sheer amount of episodes. So I decided to make
another pass at article that helps people cherry pick some of
the best episodes. With this you can enjoy many of the best bits
of Doctor Who without feeling you need to see every episode.

Tor for Technologists

Tor is in news articles a lot nowadays, but is often
misunderstood - even many technologists don't see past its
use for negative purposes. Ola
Bini, who is one of my most active colleagues working in
internet privacy, has put together an article to introduce Tor.
It covers how Tor works, together with some of the tools that come with it
(the browser bundle, hidden services). Anonymity is difficult,
so it's important to understand Tor's limitations and the
controversies about whether Tor is broken. Even if you're not an
activist, Tor is useful for testing what websites look like
without personalization and from different countries; it is also
handy for providing secure access to servers.

Don't start with a Monolith

Stefan Tilkov
is one of those pragmatic, experienced technologists that I
listen to a lot when formulating my own writing. We've been
talking recently about the applicability of microservices, and
he disagreed with much of the recent talk I've heard in favor of
a monolith-first
strategy. So he's kindly written a short article arguing
that you should
be more inclined to begin with microservices, since
monoliths rarely work out to be as well structured as you'd
hope.