This is part of my live blogging from QCon 2015. See my QCon table of contents for other posts.

Immutable Infrastructure

Never change what’s on server- no upgrading packages, no installing new packages.

We upgrade by creating a new server and deploy to it. Keep old server around just in case.

We do this to avoid configuration drift between “identical” servers. Caused by provisioning servers at different time or manual operations. Normally deal with drift by following careful instructions or automation with many edge cases. For example with parallel ssh, what if one server is down/unreachable or repo partially down. Now have different states.

Rolling back is hard because of transitive dependencies. With immutable servers have old versions of everything so rolling back is easy – switch to old server.

Reprovision servers regularly even if “nothing changed” so know can and always usig recent packages. Also, manual changes get reverted so find out while still remember problem/solution.

Improvement: golden image – Create multiple identical servers from same image. Allows to keep past versions around. Downsides: small changes are cumbersome. Even if automate, takes time. But the time a human is involved is small. Can save time with intermediate golden image. Deploy from checkpoint rather than from scratch

How to debug

Workarounds for dealing with debugging tools

• allow drift but tag as “re-imaging” and schedule self destruct. This lets you install debug tools or whatever you need.
• Install debug tools on all servers. Have feature switch to enable/disabled

How to store data

Need to retain cross server reprovisioning. One option is to use AWS or outsource. Another option is to externalie files such as putting on SAN. Or can use containers.

Containers
Can build from scratch orincremental. Simple DSL to break down the build into steps.

A Docker file is a glorified shell script. [looks like DOS it has commands like RUN git clone repo

Docker recognizes what parts haven’t changed so doesn’t re-install all the infrastructure for an incremental change such as new app code. But still get benefit of two copies – old one is still around.

Containers can share directories, logs, backups, metrics, etc since on same machine.

Can make container read only to enforce immutablity. Easier security because can’t install. Can make exception for data volumes and prevent execution in that area.

Q&A

• How to think correctly about config in container? Some in container. Some in app. What about middle ground? Can use command line params if small amount of config. Or environment variables. Or if lots of config, use a volume or repository of config and pass URL. Another approach is dynamic DNS. (use virtual names and then inject real URLs later. Let’s have redis point to different location for dev/qa/prod)
• What kinds of workloads is container tech suited for? Think any workload can be containerized. Harder to do on desktop such as Open Office. Gets easier over time because automate as more people need it.
• What is best host to run a container on? The one your ops team knows best.
• For an app with core data storage, do you need to bring apps down when update database? Yes, a tiny amount of down time. Does break existing connections/transactions. Have that when do manually too; just a longer one.

Impressions: I like the mix of lecture vs demo. And that it wasn’t very docker specific.

This is part of my live blogging from QCon 2015. See my QCon table of contents for other posts.

http://microservices.io – pattern language, best practices, etc

Gartner hype cycle

• Docker at peak of inflated expectations
• Node.js on it’s way down

How do we make decisions – elephant/rider analogy. The rider can try to direct the elephant, but it basically goes where want. The elephant is our emotions and the rider is our rational mind.

Pattern – reusable solution to a problem occuring in a particular context
Structure of a patern is a great framework for discussing and thinking about technology.

Structure:

• Name
• Context – the situation
• Problem
• Forces – issues need to address to solve problem; can conflict
• Solution
• Resulting context – consequences of using a pattern; includes drawbacks
• Related patterns – patterns that solve subproblems created by using pattern or related solutions to original problem

Pattern language – collection of related patterns – from Christopher Alexendar fom architecture

Core Patterns

• Monolithic architecture – traditional way of building an app, simple to develop/test/deploy/scale. Successful apps grow. Then have millions of line of code in one war file and beyond comprehension. No longer agile. Much fear. Infrequent deployments. Overloads IDE and container. Can’t scale. Too much coordination and communication required just to deploy. Fores into long term commitment to tech stack. Works really well on small apps because can move incredibly fast.
• Microservice architecture – apply functional decomposition – scale by splitting simiar things and/or different things and/or horizontal duplication. Amazon needs 100 microservices to render a page. Smaller/simpler apps. Lss jars/classpath hell. Easily and safely experiment with different techs. Opposite of release train. Low risk because small. Drawbacks: more complexity, inter-process communication, partial failure

Communication Patterns
What does client talk to when services distributed. API gateway is common to do request routing and API aggregation.
How do services with system communicate? Syncronous or messaging API?

Deployment Patterns

• Multiple Services per host – older approach. Like when servers were like pets and kept them alive forever efficient resource utilizatio, fast deployment, poor isolation, risk depenency version conflicts, can’t constrain resource use. Some benefits, but lots of downsides
• Single service per VM host – Netflix does this- great isolation/manageability, detailed metrics on resources using, resources constrained, less efficient resource utilization, slower deployment because creating new VM
• Service per container host – like Docker images, great isolation/manageability, container encapsulations implementation tech, efficient resource utilization because virtualizing OS. Fast deployment. Immature infrastructure for deploying containers

Discovery Patterns
For identifying microservices

This is part of my live blogging from QCon 2015. See my QCon table of contents for other posts.

This session was from the Java Sig. It’s a repeat of the conference session I didn’t attend then since I knew I’d see it here.

Java 8 has lots of new features, but people think of streams/lambdas. This session isn’t slides. It’s building a real app live. Trisha starts with an architecture diagram – small serivces and MVC layer. They aren’t microservices because they aren’t reliable. Then she has a sketch of the screen.

The code is on github.. The master branch is the whole app. There’s also a skeleton branch if you want to try it/play along. The page for this presentation has slides and video.

The Java 8 features I see go by:

• Stub Service uses a Supplier for generating random numbers.
• JavaFX for basic UI. [I’m not familiar with JavaFX.]
• Compute if absent and method reference:

  map.computeIfAbsent("key", TwitterUser::new);

• Streams, comparators

  map.values().stream()
  .sorted(Comparators.comparing(TwitterUser::getTweets)
  .reversed()).limit(10).collect(Collectors.toList();
  

• JavaFX

  laterPlatform.runLater(() -> items.setAll(x));
  

• JavaFX comes with built in animation
• Date/time to get current minute

  LocalDateTime.now().getMinute();
  

• Loop from to y

  IntStream.range(0, 10).forEach(this::method);
  

  This coud be better or worse than a regular loop in terms of readability or performance.

• Read fileStream

  lines = Files.lines(path);
  

• Filter:

  lines.filter(s -> !s.equals("Ok"));
  

• Check on stream:

  lines.peek(s -> method())
  

• Convert array to stream, map

  functionStream.of(arr).map(String:toLowerCase)
  

• Join strings with delimiter in between

  stream.collection(joining(",")
  

Intellij

• automatically shortens to simplest thing that could work making code a method reference or lambda.
• Keyboard shortcut to use appropriate functional interface. Complicated shortcut, but nice function