events amsterdam software circus

Software Circus 2016 - Amsterdam

To the Cloud and Beyond

Thursday, September 1, 2016

My personal notes from this three day kick-ass conference about Cloud Native Computing

31 August, 1-2 September 2016 Pakhuis West

Day 1

Wednesday August 31st, the pre-conference workshop day.

Workshop from Zero to Hero

by Stuart Williams, Product Manager at Weaveworks

Pre-reqs:

Workshop:

Note 1: minikube running causes trouble (used ports and identical name conflicts) Note 2: running the demo the first time takes some time, be patient. Start Weave Scope first to see what is going on.

Day 2

The first day packed with sessions.

When Containers Attack

by Anne Currie, Co-founder at MicroScaling Systems, @microscaling, @anne_e_currie

Divers(ity) vs Monoculture

“Division of labour has caused a greater increase in production than any other factor. This diversification is greatest for nations with more industry and improvement” - Adam Smith, “The wealth of Nations”, 1776

Tip: Do not read the whole book, read the overview or go for the abstract from the Adam Smith Institute.

Diversity is key to innovation.

Specialization can enhance production by a magnitude.

Labour = People (roles) + Technology (and organized with processes)

Diversification between technology and role was good in the Industrial Revolution. But what about the Software Revolution.

The full-stack-engineer: The full-stack-engineer

The Zombie Apocalypse Team; Team Leader, Brawler, Weapons Expert, Brains, Medic, Speed Fighter, Mascot, Guy-who-dies-first. Or is the full stack engineer required?

Technology: Specialist-Tech or One-stop-shop?

“Conference speakers are professional enthusiasts”

Metadata for Containers (sidestep and some shameless self-promotion ;):

“There is no perfect technology for everything.”

Specialism creates lock-in. Specialism needs to be managed.

Tech diversity key to industrial revolution => large productivity increase thru specialisation.

Hard with evolving requirements or small companies.

Q: Is the modern equivalent cloud services?

My thoughts: Instead of giving answers Anne directs us to the two opposing entities. Generalization vs specialists. It gives food for thought but still leaves me a bit unsatisfied.

Seven counter-intuitive experiences you are about to have when you go cloud native

by David N. Blank-Edelman, working at Apcera, @otterbook

“Culture determines and limits sttrategy” - Edgar Schein, “Organizational Culture & leadership”, 1985

“Stabilize…Rationalize…Optimize”, Lean $thing (John Fanuko)

“Stabilize…Optimize…Transform”, Lean Transformation (Holger Reinhardt)

Make a reliable system with unreliable parts.

Reduce risk with small releases Reduce Risk with small releases from The Startup Patterns Book

The borders are where the action is.

My thoughts: The very long title of the presentation (I shortened it here) is an indicator of how anxious this guys is to speak at a conference. Powerful one-liners but the overall message did not stick and I could not make myself write down the 7 counter-intuitive experiences. However one of the takeaways from this session is the reference to The Startup Patterns Book, wisdom for small and large startups.

The how and why of Windows Containers

by Ben Hall, Founder of Ocelot Uproar, KataCoda, @Ben_Hall, Ben@benhall.me.uk, OcelotUproar.com / KataCoda.com

Windows Server 2016 Windows Server 2016:

  • Windows Server Core
    • Nearly Win32 compatible.
    • Same behaviour of Windows.
    • Install all of the same tooling.
  • Windows Nano
    • Stripped down.
    • Smallest footprint.
    • 1/20th the size of Windows Server Core.
    • Only essential components: Hyper-V, Clustering, Networking, Storage, .NET, Core CLR.
  • Windows Containers
    • Windows app containers.
  • Windows Hyper-V Containers
    • More secure Windows app containers.

Containers can run apps like SQL Server, MSMQ and IIS/ASP.NET. Windows (Hyper-V) Containers

Hyper-V containers offer an extra layer of protection. Therefore well suited for shared hosting and multitenancy environments.

Microsoft_Container_Runtimes.png

Windows Compared to / Usage
Windows Server Ubuntu Linux
Windows Nano Alpine Linux
Windows Server Core Legacy Apps?
Windows Nano Modern Apps?

NSSM - the Non-Sucking Service Manager, nssm is a service helper which doesn’t suck.

Windows vs Linux container

Windows Linux Subsystem:

  • Completely unrelated
  • Maybe not in the future …

Docker on Windows can mount disks (d:)

Properties of Windows Utility VM:

  • Invisible to Docker and containers
  • All write are degraded
  • Separate Kernel to host
  • SMB file share to access host data
  • In the future use for Linux containers?

Kubernetes: Add Windows Container Support

Apache Mesos for Windows Server mesos_on_windows.jpg

Resin.io, update your Linux device fleet over the air.

Microsoft confirms built-in Hyper-V containers are coming to Windows 10 testers soon.

My thoughts: Good overview of the upcoming container technology coming form Microsoft. Containers on Windows 10 is going to be the next thing but how this will be used by the masses is still unclear to me. Microsoft does not invest in things, because it can, so what is the story behind it? What is their long-term strategy?

Do take a look at Ben Hall’s KataCoda, a free interactive demo and training environment. KataCoda

Infraloop, Advance Orchestration Concept

by Adam Sandor, Senior Developer at Container Solutions, @adamsand0r

Infraloop is the meta-orchestrator that is build on top of the Kubernetes and Mesos orchestrator APIs.

Application (application aware of orchestration):

  • Run the right number of different containers
  • React to Queue length
  • React to Slowness

Policy Engine (policy-based orchestration):

  • Minimize cost
  • Maximize performance
  • Keep capacity limits

My thoughts: What problem is solved with this Infraloop? Hooking into the APIs to tune the clusters, sounds like a good reason but this could also work for a single orchestrator. With the right parameters, function or algorithm you could make a independent self-healing fully optimized system.

The Sock Shop: Microservices from dev to prod
 with Docker, Swarm and ECS

by Luke Marsden, entrepeneur at Weaveworks, luke@weave.works

Microservices!

  • Small, simple, self-contained
  • Maintained/upgraded/deployed separately
  • Seperate database
  • Whatever language you like

Weave Scope: Automatically detects processes, containers, hosts. No kernel modules, no agents, no special libraries, no coding. Seamless integration with Kubernetes and AWS ECS.

Weave Net: A simple and resilient container SDN portable across data centers and public clouds.

WeaveDNS: WeaveDNS is a DNS server that answers name queries on a Weave network and provides a simple way for containers to find each other.

Weave Net + WeaveDNS

  • Container overlay network
  • IP per container, no port mapping
  • Auto-registration in WeaveDNS for service discovery
    • e.g. frontend connects to accounts.weave.local

Weave Mesh = Gossip + CRDTs

  • Golang library used by Weave Net & WeaveDNS

CRDTs (Conflict-free replicated data type):

  • Merge operation ⊕ for data structure such that:
  • Associative: A ⊕ (B ⊕ C) = (A ⊕ B) ⊕ C
  • Commutative: A ⊕ B = B ⊕ A
  • Idempotent: A ⊕ A = A

Example of CRDTs:

  • Add-only set
  • Latest-value-wins singleton (using timestamp)
  • Set with deletion: give every element an id, maintain a set of “deleted elements” using add-only set
  • Many more… http://arxiv.org/abs/1608.03960

Using Weave Mesh:

  • General form of update: A ⊕ B = C
    • A: local state,
    • B: incoming state,
    • C: resulting state
  • Golang interface:
    • mergeReceived = B
    • mergeDelta = difference from A to C
    • mergeComplete = C

Benefits:

My thoughts: Not much sock-shop talk but some really interesting tools were displayed. At the workshop I already saw Weave Scope at work and I was impressed by it. In this talk Luke took it to the next level, showing of the other tools from WeaveWorks.

What is Cloud Native and why does it exist?

by Alexis Richardson, CEO at Weaveworks and chairman of the TOC for CNCF Cloud Native Computing Foundation

Open Source Cloud Computing for Applications, a complete and trusted kit for modern architectures.

Lessons learnt: the tools have to be cloud native too

  • “Invisible Infrastructure”
  • Customers want to migrate applications to the cloud, but keep some parts behind the firewall, for flexibility or cost reasons
  • They want to the ability to change cloud providers - no “lock-in”
  • They want everything to “just work” so they can focus on app

Recommended presentation: Netflix Development Patterns for Scale, Performance & Availability (DMG206) | AWS re:Invent 2013

Assumptions

Recommended reading: Puppet 2016 “State of DevOps Report”

Some nuggets from the report:

  • High-performing IT organizations deploy 200 times more frequently than low performers, with 2,555 times faster lead times.
  • They have 24 times faster recovery times and three times lower change failure rates.
  • High-performing IT teams spend 50 percent less time remediating security issues.
  • And they spend 22 percent less time on unplanned work and rework.
  • Employees in high-performing teams were 2.2 times more likely to recommend their organization as a great place to work.
  • Taking a lean approach to product development (for example, splitting work into small batches and implementing customer feedback) predicts higher IT performance and less deployment pain.

Lesson Learnt: Cloud Native needs good tools

  • Open source
  • Run anywhere
  • Software you can trust, managed by credible teams & processes
  • Easy to monitor and control
  • Interoperates with other tools and common conventions

Lesson Learnt: the infrastructure has to be boring

  • To focus on your app, the infrastructure has to be boring.
  • Use PaaS/CaaS or any container platform you like.
  • Watch out for the 1% failure problem

Lesson Learnt: We need good PATTERNS

  • Microservices (and Microliths)
  • Cattle not Pets
  • Observability and Control baked in
  • Traffic Patterns - Blue/Green, Canary, smart routing & load balancing …
  • …

Cloud Native is Patterns

Patterns for Availability, Automation, Acceleration, Anywhere!

The Linux Foundation: Safeguards Linux for the long term. Provides a nexus for collaboration and trust. Is an ubiquitos open source brand. Good for customers & the community!

Common Open Source is not proprietary

Software is eating the world. Open Source is eating Software. Cloud is eating Open Source. - @monadic

Tools you can trust, high quality, high velocity projects:

Cloud Native Reference Architecture

Docker Platform and the Docker Runtime are currently dominant in the Orchestration & Management and the Runtime layers. The ecosystem is asking for a core standard container (appc), stability (LTS releases) and an open platform.

My thoughts: Inspiring session providing lots of insights. Many references and guidelines. The closing sheets refer to the possible lock-in by Docker and its ecosystem and a call for an open container platform. I’m not sure what to think of that. Isn’t Docker Open Source?

Day 3

The last day of the conference.

Surprise Keynote

by Peter Jacobs, CIO at ING

“To improve is to change, to be perfect is to change often” - Winston Churchill

“Our customers expect simple, personalized and instant customer journeys.”

In our new way of working we learnt valuable lessons and had to give up some of our habits:

  • Agile is not only IT, it’s end to end
  • Select the right people and build an engineering culture
  • There is no partial agile
  • Change performance management, more focus on the team
  • Empower your people, employee = entrepeneur
  • To innovate, you must learn to make mistakes
  • Agile = fun!

ING’s “IT Control Frameworks” and “Security/Risk Processes” play an important role in our daily jobs but their current implementation and processes …

  1. lack traceability to value
  2. impede the autonomy of the squads > Bottlenecks, wait times, complexity (= ± 15% of the work of the Squads)
  3. are ineffective at controlling a complex adaptive system
  4. lack integrated automation (Continuous Delivery - and Infra Provisioning pipelines)
  5. impede global collaboration
  6. are not competitive anymore, we must re-invent ourselves

“New tools do not solve process issues.”

“Infra guys need to be software engineers”

The Assembly Platform is based on architecture principles that encompass our vision for the future bank

  • “Outcomes over Impositions”
  • “Standard way of Working”
  • “Lowest Common Denominator”
  • “Shift Left”
  • “Immutable Servers”
  • “Cattle over Pets”
  • “Infrastructure is Code”
  • “Code is Forever”

My thoughts: ING has a clear vision on how to sculpt their IT for the future. Their architecture principals seem a bit radical but for a cultural change this magnitude probably necessary. The principles are written down very cryptic and need elaboration. I asked for this but have not received that info.

Logging all the things

by Philip Krenn, Developer Advocate at Elastic, @xeraa

Elastic Stack:

  • Elasticsearch doing the hard work of analyzing and searching large amounts of data.
  • Logstash for parsing and enrichment.
  • Beats as a lightweight agent or forwarder.
  • Kibana for powerful visualizations.

Kibana, Elasticsearch, Logstash and Beats

Elastic Stack is Open Source, the commercial part is X-Pack. X-Pack offers; Security, Alerting, Monitoring and Graph.

Elastic Stack + X-Pack = Elastic Cloud

Logstash has a large footprint, Beats are lightweight datashippers installed as agents on your servers to send specific types of operational data to Elasticsearch.

Beats by Elastic: Filebeat, Metricbeat, Packetbeat

Community Beats: DockerBeat, Springbeat, Journalbeat, Nagioscheckbeat, libbeat

https://hub.docker.com/u/elastic/

Give it a try https://github.com/xeraa/vagrant-elastic-stack

My thoughts: The ELK-stack is growing, with the modular Beats and lightweight setup it is now possible to monitor containers. Definitely worth a try.

But I don’t want all my packets to get from A to B (and the less said about C, the better)!

by Ed Harrison, Core Developer and Evangelist at Tigera, Inc

Networking becomes more and more complex, typical network structure; firewall on the outside and inside it’s a mess. Traffic flowing across the wires between devices visible to all applications.

Segmentation is needed and only traffic between the applications on the ports needed.

project Calico

Calico provides a pure L3 fabric solution for interconnecting Virtual Machines or Linux Containers (“workloads”). Instead of a vSwitch, Calico employs a vRouter function in each compute node. The vRouter leverages the existing L3 forwarding capabilities of the Linux kernel, which are configured by a local agent (“Felix”) that programs the L3 Forwarding Information Base with details of IP addresses assigned to the workloads hosted in that compute node. Felix also programs Access Control Lists in each compute node to enforce whatever security policy may be needed, for example to provide isolation between tenants. The vRouter function makes use of Border Gateway Protocol to advertise (typically) /32 or /128 routes to workloads hosted in each compute node. The BGP stack in each compute node is connected to a virtualised BGP Route Reflector to provide scalability of the control plane.

Calico connects each workload via the vRouter directly to the infrastructure network. There is no overlay, no tunnelling, no VRF tables. There is also no requirement for NAT in a Calico network, since any workload can be assigned a public IP address which is directly reachable from the Internet – provided you configure a security policy to allow this.

Slack: slack.projectcalico.org Github: github.com/projectcalico Web: projectcalico.org Blog: projectcalico.org/blog Twitter: @projectcalico & @eepyaich

Article with background info: Why Calico?

My thoughts: Project Calico seems to be a very interesting approach to SDN, a clean and simple solution based on standard protocols and inspired by the internet. Both NSX and Calico embrace micro segmentation only their implementation seems different but that is something that needs further investigation.

Cisco room, after the session

Serverless-less server?

by Michael Hausenblas, Developer & Cloud Advocate at Mesosphere, @mhausenblas, mhausenblas.info, michael@dcos.io

Slides at Speaker Deck

Serverless compute is the new black but there is a lot of confusion around what it is and when and how to use it.

Serverless = Function as a Service (FaaS) the FaaS name did not stick therefore it’s Serverless Computing.

Building and Releasing Apps

A spectrum of Compute Styles

How fast can a feature be deployed?

What are the Costs? Same goes for maintenance.

Concept

  • unit of compute: a function
  • dynamically allocated resources for event-driven function execution
  • high-level components: triggers, management, integrations

Motivation for the Serverless concept: “function as a deploy unit”

Sample app Flock-of-birds

When and how to use:

  • Infrastructure tasks,e.g. reacting to an event triggered from cloud storage
  • Mobile and IoT apps: process events such as a user check
  • Image processing: for example to create preview versions of an image Data processing: like simple ETL pipelines to pre-process datasets

Use cases:

Challenges:

  • workload fit
  • developing functions
  • monitoring
  • statefull services
  • cultural and organizational issues

Serverless: latency tolerant, low frequency

appops: “The person who writes an app is also the person responsible for operating the app in prod."

appops: “It’s not about provisioning, capacity planning, DR, etc. … this would be on the infrastructure team.”

CHARITY.WTF blog

Michael is writing a book on Serverless Ops (O’Reilly).

Jitsu, just in time serverless unikernel.

My thoughts: The next wave in compute styles, the name does not cover it’s meaning but I do think that this is where we are heading. Focus on those things that are actually needed. Programming functionality and care less about the underlying system. What started with PaaS, Heroku and Cloud Foundry continues with Serverless computing. This compute style is not suited for everything but it will certainly find its place among the other compute styles.

Unik: A platform for automating unikernels compilation and deployment

by Scott Weiss, Software Engineer at EMC, @ilackarms missing Idit Levine, CTO of Cloud Platform Team at EMC-Advanced-Dev

Virtualization stack contains a lot of redundancy Virtualization Stack

Inefficiency:

  • Needless permission check, it is hard and an updated model from time sharing computer from the 50s and 60s.
  • Microservices architecture duplicates what L:inux did for us.
  • Kernel include a lot of unnecessary drivers that not being used: floppy, USB …
  • Update and patches using yum bring a lot of unnecessary components.

Security:

  • Very large attack surface.
  • A lot of exploits target Linux. It is harder to attack hypervisor - not expose to the internet.
  • Microservices architecture; Sharing - Kernel, Memory, filesystem, hardware. The only thing make it safe is kernel extension like cgroup.

Unikernels:

  • Cross-compile applications into minimal machine images.
  • Boot virtual machines or bare-metal difrectly from Unikernel - the OS is ‘baked in’.
  • The application and the kernel are one.

Traditional approach

Unikernel approach

Unikernels (WikipediA):

  • Single address space, single-process operating system
  • No virtual memory isolation
  • No context switching
  • No usermode/kernelmode

Docker stack vs. Unikernel stack

Unikernel implementations:

  • Backward compatible; POSIX compliant
  • Forward compatible; language specific

UniK UniK: an open-source tool written in Go for compiling and deploying unikernels. Docker inspired CLI tool.

UniK: Build and Run Unikernels with Ease

UniK integration with Kubernetes and Cloud Foundry.

Mirage vs Rump unikernels

Unikernels running on rPi.

Unikernels.org by Mirage.

Systemlevel programming. Go is really well suited for this.

Unikernel-VM

My thoughts: Does it run on all hypervisors? Hypervisor is a provider in UniK. How do the different unikernel implementations compare to each other? Lots of questions but this has potential! Running a unikernel on an rPi or a cluster of them, wow what a utilization of these resources. This could be an answer to all the bloated systems out there at the moment, also security is a very good reason to dive into this technology. The attack surface is minimal.

Building apps for an Internet-sized computer

by Ben Firshman, Director of Product Management at Docker, @bfirsh, b@fir.sh

Serverless lets you run code on the internet

But computers are so much more than running functions

Serverless Docker

My thoughts: Hmm, well it was the end of the conference and to be honest for me this was not the best (most inspiring) speaker. I probably missed the point of his presentation or I’m just not capable of comprehending the deeper layers in it. Most of it was also covered in the presentation by Michael Hausenblas.

Wehkamp labs

Wehkamp labs logo www.wehkamplabs.com

Wehkamp labs showed a banner with the tooling they currently use:

Scalable Infrastructure:

Reactive Architecture:

Rapid Development:

Data Driven:

ToC