Observability

Robust observability, if implemented, will provide the first tangible benefits of the new platform. By observability we mean the 3 pillars - logging, metrics and tracing. OpenShift does come with it’s own built-in logging and metrics infrastructure but with a little bit of plumbing we can get a best of breed monitoring solution. Some examples of this plumbing work are: forwarding the logging via fluentd to an enterprise-wide platform like Splunk, implementing Prometheus-based metrics monitoring, interpreting audit logs and tying up with alerting systems, implementing service-mesh and tracing solutions. The ability to monitor the system deeply and pinpoint issues provides a shot in the arm for any platform or application team.

Security

OpenShift comes security-hardened out of the factory, with plenty of built-in constructs like secrets, service accounts, security context constraints, RBAC and identity provider integrations. A whole range of additional security measures may be implemented, from scanning of images, to audit and security analysis, to running to chaos tests, not the least adhering to best practices for managing such infrastructure. Attack surface area can be diminished by addressing vulnerabilities at host, platform, and container levels. When it comes to security, more is always better. Maintaining a principle of least access, ie, granting privileges only when necessary, together with a shared DevSecOps model will minimise attack vectors.

Backup, restore, upgrades

Taking regular backups are table-stakes while managing any serious infrastructure platform. In the case of a multi-tenant platform like OpenShift this may be a shared responsibility of the tenants and the platform teams. The entire cluster definition maybe backed up by performing an etcd backup, while the data-backup (of registry and similar infra components) maybe implemented via the backup procedures of the underlying persistent storage. Do not be afraid to regularly test the etcd backup and restore - fail sooner and learn fast! Another moment of test of stability is during upgrades. With each release the upgrade process is getting simpler, but there could always be breaking changes, so the release notes are an important accompaniment. As a general practise it is recommended to keep up with the OpenShift release cadence without too long a delay.

Resource utilization

OpenShift allows administrators to allot and ration compute, memory and network resources to each tenant at a granular level. Enforcing resource limits at namespace and cluster levels ensures that no runaway application can hog cluster resources. Cloudforms can be used for calculating infrastructure costs, and report to development teams on their resource consumption, with the possibility of implementing chargeback.

Persistent storage

At an early stage during the implementation of the platform it becomes clear that we need persistent storage in order to retain the state of the cluster, the registry, and applications. While OpenShift offers a robust persistent storage mechanism in conjunction with many types of backends (filesystem-based and block-based), it is usual practise to just start using NFS as storage backend simply because it is easy and known to most system administrators. Sooner than later, it becomes imperative to look at dynamically provisioned storage backends such as GlusterFS, AWS Elastic Block Store, GCE Persistent disk, etc. Dynamic storage provides great flexibility to administrators, and allows users to request for storage without having any knowledge of underlying infrastructure.

Human Ops

For all the technical measures listed above, a key ingredient is the human element. How is the platform Ops team organised? How will the team deliver its services to tenants of the platform? How will the team keep up with the new features and ever changing technology landscape? In my opinion, the team should focus on automating as much as possible, while ensuring that underlying infrastructure complexity is invisible to development teams. Google’s SRE book is a great reference and starting point for any team that plans to implement and deliver OpenShift services. In addition to that, following the official documentation and Github forums can keep the team close to the technology and increase their own confidence in the platform.

There were a few themes and announcements in this edition, like operators, efforts on serverless, service mesh, SPIFFE, etc. The highlight for me however was the “hallway track”, where I bumped into quiet a number of peers and end users from all kinds of business. Plus having one-on-one chats with the who’s who of the industry like Joe Beda and Kelsey Hightower was icing on the cake. Because I arrived in Copenhagen a day prior I could also attend a couple of workshops and the Red Hat commons gathering.

In true open source spirit, the CNCF makes video recordings from the event available online, and this time it got everything (over 300 sessions) uploaded within 2 days of the event. That is worth months of binge watching. Therefore, to make things somewhat simpler here is a cherry-picked list of 5 of the most notable keynote talks which capture a good essence of the event.

CNCF 2020 Vision by Alexis Richardson, Founder & CEO, Weaveworks
If there is one talk that you can watch to get up to speed to what the CNCF is all about, it is this one. I have seen Alexis’ talks previously too, and the clarity with which he lays out the vision is pretty amazing.

Serverless, Not So FaaS - Kelsey Hightower, Kubernetes Community Member, Google
CNCF is assuming a key role in bringing about standardization of serverless technology. In his keynote, industry celebrity Kelsey Hightower explains how this is happening and introduces the cloud-events project.

Crossing the River by Feeling the Stones - Simon Wardley, Researcher, Leading Edge Forum
This is a talk about strategy, situational awareness, maps, patterns and serverless. This has to be one of the best talks I have ever heard at any event, and had the audience in splits.

Anatomy of a Production Kubernetes Outage - Oliver Beattie, Head of Engineering, Monzo Bank
Talking about your failure in front of 5000 people takes guts. In this talk Oliver does just that as he dives deep into a production outage. Very valuable lessons learnt from this talk.

Software's Community - Dave Zolotusky, Software Engineer, Spotify
Spotify has made great technical accomplishments, but here Dave talks all about the people aspect, and how he leveraged the community to get help accomplish things.

So those were my top 5 general talk picks from the KubeCon. Apart from these, I totally loved some of the deep dive sessions on kubeadm, istio, SPIFFE, etc. You can find those and more at the playlist: https://www.youtube.com/playlist?list=PLj6h78yzYM2N8GdbjmhVU65KYm_68qBmo

PS: A version of this blog was published on the Devoteam website.

However, there still remains the question of monitoring the several hundred microservices, as well as the platform that runs them. With many moving parts comes a vital necessity, one that has recently gained much popularity in cloud-native parlance – “Observability”. In this blog we look into how we can leverage observability in Red Hat’s OpenShift Container platform.

The case for Observability

But first, what does Observability mean? People often use the terms Observability and Monitoring interchangeably. My plan is not to go into the semantics here. Distributed systems expert Cindy Sridharan discusses the topic in her seminal blog post “Monitoring in the Time of Cloud Native”. To me, Observability in simple terms, is the attribute of a system that exposes data about itself that one can easily access. It is the ability to know what is going on, but also why. An “observable” system is one that opens up its vital statistics for easy whitebox monitoring.

“The more visibility you give to people, the less access you need to give them to the infrastructure.” – says Kubernetes guru Kelsey Hightower at the KubeCon in Austin, December 2017. For operations folk, this means a way to both securely monitor the platform and diagnose issues without having to SSH into a machine. As for a developer, this is the ability to easily trace and correlate request flows between hundreds of services.

Prometheus for OpenShift: a great fit

Observability is usually grouped in 3 so-called pillars: logging, metrics and tracing. Here we focus on metrics, in particular how we can examine metrics from an OpenShift cluster by leveraging the latest version of Prometheus. Metrics are basically numbers of vital statistics that are aggregated over time. OpenShift inherits the observability built into Kubernetes, and therefore metrics about CPU, memory, network, etc are exposed by the kubelet which are made available by Heapster. OpenShift uses Hawkular as its integrated metrics engine to gather and expose metrics from running pods. With version 3.7 of OpenShift, Prometheus has been added as an experimental feature, and is slated to replace Hawkular as the default metrics engine in a few releases.

Prometheus is a metrics monitoring system that is built with a cloud-native approach to monitor services. It is also a time-series database, a query language (PromQL) to query the time-series, and a dashboard. The modus operandi of Prometheus is “scraping targets”, or in other words, pull metric information from configured sources. It does this at regular intervals, which is again, configurable, and stores these metrics as a time-series in its database. The Prometheus community has put together a great documentation with concise instructions and best practices.

Although Prometheus has been around for a while, with the recent release of its version 2.0 is witnessing a big spurt in adoption. This has among other factors to do with significant improvements in how Prometheus handles storage. Prometheus was also the second open-source project to be adopted by the Cloud-Native Computing Foundation (CNCF) after Kubernetes, and in all sense is a perfect fit for monitoring OpenShift.

Plugging in Prometheus and other components

There are several ways to install Prometheus in OpenShift (a neat example here), but importantly the right ports on the cluster nodes must be opened to let the Prometheus pod connect. Once deployed, Prometheus can gather and store metrics exposed by the kubelets. Of course, you can configure more targets (like routers, underlying nodes, etc) and it will scrape metrics from them too. The scrape configuration is loaded into the Prometheus pod as ConfigMaps. All the gathered metrics are stored in a time-series database locally on the node where the pod runs (in the default setup).

In order to gather statistics from within your own application, you can make use of the client libraries that are listed in the Prometheus website. You can use them to instrument Prometheus metrics and expose them from within your application, usually via a /metrics endpoint. For operators, it is handy to have more information about underlying nodes than that exposed by the kubelets. For this you can make use of node-exporter, with which you can collect hardware and OS metrics. A whole lot more of exporters for different metric sources are listed on the Prometheus website.

While one can gather and store metrics using Prometheus, we also need to setup alerting and dashboarding for good old cluster-ops. We can set up alerting via Alertmanager which we can use to trigger alerts to external alerting systems, email, slack, pagerduty, etc. As for dashboarding, Prometheus itself comes with a simple query and graphing feature, but it is common to integrate a full-fledged dashboard tool such as Grafana.

One caveat to bear in mind is that Prometheus is not built for long term storage, so if we want to collect long-term statistics we should use adapters to send the metrics to external databases like InfluxDB. It is hoped that long term storage capability will be provided built-in with OpenShift when it’s Prometheus integration reaches full feature status.

Get some actionable information

Armed with the necessary monitoring tools, we now arrive at the topic of “what” to monitor. For applications, the most interesting metrics to get started would be number of requests, response times, error rates, etc, next to specific cases needing investigation. For operations, it’s the possibility to monitor cpu, memory, latency, and just about everything the kubelet and other exporters can provide, over individual containers to cluster-wide scopes. Resource utilization information is useful to manage and determine quotas and cluster expansion decisions. One cool thing with prometheus is that we can use OpenShift selectors as filters while querying the time series. The Prometheus query browser is your friend, and as obvious the possibilities are endless. Alerting can be setup on the collected metrics to aid proactive problem detection. The observability achieved should help not only to track back to what happened in the past, but also to improve future performance.

As mentioned before, Red Hat is clearly moving towards a Prometheus based metrics engine for future versions of OpenShift, which is indeed a good sign. OpenShift already has a good logging infrastructure with its integrated EFK (Elasticsearch-Fluentd-Kibana) stack. Red Hat also has plans to incorporate tracing and service mesh solutions into the OpenShift platform, thus promising Observability across all the three pillars.

PS: This blog post was published on devoteam.com

I am not a big fan of predictions in tech business. I have seen a number of prediction articles on the web lately featuring all the hot keywords. They do to attract eyeballs I must admit. In this blog though, I list out a few other industry trends of the moment, which are also likely to pan out in 2018. Let me add the disclaimer, these aren’t predictions.

Cloud’s Big 3

Firstly, it would be interesting to find what new the big 3 cloud vendors bring out their stables in 2018. I am particularly interested to see whether Google catches up or falls further back with the other two.

Containerisation

As much as we want to think futuristic, a large percentage of the world is still just starting out on microservices and containers, and therefore we should expect to see continued new entrants and investment in this space.

Service mesh

Service mesh technology is climbing up the hype cycle and still evolving. Companies which are running 100s or 1000s of microservices on production are already looking into service mesh tech like istio, envoy, etc instead of more traditional API management tooling.

Container-native storage

Staying on containerization, CNS (Container Native Storage) standards should mature driving enterprises to invest in container-native storage technology.

Serverless

Serverless (or FaaS) seems to gather good initial adopter tailwinds and is likely to get a lot of attention in 2018. Curious how serverless technology evolves and whether it would augment or challenge PaaS platforms.

A few more

A great deal of innovation is coming from opensource and should be more and more so. There is a lot of activity now around AI and this is bound to influence some of the areas mentioned above. Other trends like VR and IoT seemed to be flattening over the last year, whereas "edge-computing" seems to gain ground. Blockchain has been generating a lot of corporate noise riding on cryptocurrency bullruns but are yet to prove if they are not just hot air.

Establish baseline knowledge

One challenge the team doesn’t need to deal with when starting with scrum is team members who lack a baseline knowledge of scrum framework. Send all team members to a scrum training, if they require it. Send the Product Owner to a PO training if he hasn't followed one. Additionally, ensure the person serving as PO is able to set priorities to the product or service, and has a wider organisational view.

Time-box everything

The only way a scrum event (refinement/review/standup/...) doesn't become a chore is when the team members derive value out of it. Too often these meetings tend to drift into one-sided discussions, rendering attendees thinking "what am I doing here". Time-boxing can be an effective tool to control this drift. Time-box discussions to 5 or 10 minute windows and set an alarm on your phone or browser. When the alarm goes off, let the team vote (with a simple thumbs up/down) whether to continue the discussion for another 5 minutes.

Story readiness

One of the very useful checklists we developed is the "Definition of ready". Anyone can create a story on the product backlog, but it is the ultimate responsibility of the PO to take those stories in. The PO sets priorities, and makes use of the simple "Definition of ready" checklist before pushing the story into the "Ready-to-Poker" status (during what we call "grooming" sessions). Thus, when the team assembles for the refinement session, it has all the information it needs to poker stories effectively. You might have guessed (rightly) we used JIRA.

Sprint goals

One of the challenges we had to deal with is defining what our sprint goals are. Of course the PO has to make a call here, and this must align with longer running epics or themes. In practice, setting limited achievable goals per sprint has been elusive as the team tends to work on multiple epics at the same time with more or less similar priorities. A particularly tough one is how to handle "unexpected" work: create adhoc stories mid-sprint, or handle them in a planned "bucket"?

Daily scrum & Retrospectives

It is safe to say the success of a scrum effort depends on the sanctity of these two particular events. Proper daily scrums forge a sense of team as nothing else. Make sure all necessities for a daily scrum like fixed space, time, visual props, etc are arranged. Keep the communication crisp, and natural (the SM should take backseat). The whole idea around scrum is about inspect and adapt. This is made possibly by a frank and free retrospective session. Remember that this is the time to talk about how things are going with the team, and not anything technical or backlog-related. Try to get action points out of the session, each assigned to someone. Again, time-boxing (see above) is essential in both these events.

In conclusion, scrum should help create a team out of individuals, with focus on the product/service it delivers. However, a lot depends on the individuals playing their parts, be it the SM, PO or team member. The key is not to do scrum as a goal unto itself, but as a means to help the team deliver its goals.

For a quick head-start on OpenShift fundamentals I recommend reading this website. For more detail on architecture and components, the best place to go is the Red Hat official documentation.

OpenShift is available in many flavours.

• OpenShift Origin - The upstream open-source version, built upon Kubernetes and other projects.
• OpenShift Enterprise¹ Openshift Container Platform - Red Hat’s flavour of Openshift platform for on-prem or cloud deployment with support.
• OpenShift Dedicated - Same as Openshift enterprise, but hosted as a cloud-based service by Red Hat.
• OpenShift Online - A fully managed on-demand PaaS on cloud with limited memory and storage.
• Red Hat CDK - Container Development Kit, a stripped-down version to serve as a local environment for developers.
• openshift.io (not GA as of writing) - A fully cloud-based development environment.

Many indeed! But for this blog I choose the Red Hat CDK, the easiest way to get up and running. The CDK will provide a developer-ready single node OpenShift cluster. Typical use cases of the CDK environment would be to do local development, demos, or simply to familiarize with OpenShift.

Installation and setup

With the release of the new CDK version 3.0 the setup is extremely simple. It will spin up a Red Hat VM on the hypervisor of choice, and then create a single node Openshift cluster on this VM. I use macOS with virtualbox (default) for this setup.

• Join the Red Hat Developers program and obtain a free Red Hat Developer subscription.
• Download the installer from Red Hat Development Suite.
• Run the installation and select Red Hat Container Development Kit components from the installer menu.

For additional options or other OS/hypervisors refer to Red Hat documentation.

The CDK comes bundled with the minishift and oc binaries that you can use to interact with Openshift. To set up the CDK cluster,

• Set and export the variables MINISHIFT_USERNAME and MINISHIFT_PASSWORD with your subscription account.
• Start minishift to create the minishift vm and provision a single-node Openshift cluster over it

$ minishift start
Starting local OpenShift cluster using 'virtualbox' hypervisor...
Registering machine using subscription-manager
... 
   OpenShift server started.
   The server is accessible via web console at:
       https://192.168.99.100:8443

   To login as administrator:
       oc login -u system:admin

• To set the oc binary to your path, run:
  eval $(minishift oc-env)

You now have an Openshift cluster at your disposal complete with a master-cum-node host, built-in docker registry, router, internal etcd store, etc. You can check the versions you got:

$ oc version
oc v3.5.5.8
kubernetes v1.5.2+43a9be4

Deploy an application

• Login with the developer account: oc login -u developer -p developer
• Create a new project

$ oc new-project cdk-intro
Now using project "cdk-intro" on server "https://192.168.99.100:8443".

The project is created and you are automatically "inside" that project's namespace.

• Now let's deploy an application to this project. We will deploy a sample nodejs app from github here at https://github.com/openshift/nodejs-ex. We will use OpenShift's source-to-image (s2i) feature. This is the sequence events that will occur:

• OpenShift pulls the source code from github and determines what type of application this is, ie, nodejs.
• Choses a builder image that matches nodejs
• Builds the application image and pushes it to an imagestream.
• This will automatically trigger a build followed by a deployment. At the end of the deployment we will have the application deployed as a service available at an endpoint.

$ oc new-app https://github.com/openshift/nodejs-ex -l name=my-app
--> Found image 2e621c4 (12 days old) in image stream "openshift/nodejs" under tag "4" for "nodejs"

    Node.js 4 
    --------- 
    Platform for building and running Node.js 4 applications

    Tags: builder, nodejs, nodejs4

    * The source repository appears to match: nodejs
    * A source build using source code from https://github.com/openshift/nodejs-ex will be created
      * The resulting image will be pushed to image stream "nodejs-ex:latest"
      * Use 'start-build' to trigger a new build
    * This image will be deployed in deployment config "nodejs-ex"
    * Port 8080/tcp will be load balanced by service "nodejs-ex"
      * Other containers can access this service through the hostname "nodejs-ex"

--> Creating resources with label name=my-app ...
    imagestream "nodejs-ex" created
    buildconfig "nodejs-ex" created
    deploymentconfig "nodejs-ex" created
    service "nodejs-ex" created
--> Success
    Build scheduled, use 'oc logs -f bc/nodejs-ex' to track its progress.
    Run 'oc status' to view your app.

• We can view the status of the app as follows:

$ oc status
In project cdk-intro on server https://192.168.99.100:8443

svc/nodejs-ex - 172.30.35.237:8080
  dc/nodejs-ex deploys istag/nodejs-ex:latest <-
    bc/nodejs-ex source builds https://github.com/openshift/nodejs-ex on openshift/nodejs:4 
    deployment #1 deployed 4 minutes ago - 1 pod

• Let's expose the service and get a route to access it.

$ oc expose service nodejs-ex
route "nodejs-ex" exposed

$ oc get route
NAME        HOST/PORT                                   PATH      SERVICES    PORT       TERMINATION   WILDCARD
nodejs-ex   nodejs-ex-cdk-intro.192.168.99.100.nip.io             nodejs-ex   8080-tcp                 None

The application is now accessible at http://nodejs-ex-cdk-intro.192.168.99.100.nip.io.

OpenShift integrates well with developer IDEs like Eclipse. Read Samuel Terburg's blog for a complete list of local development options.

Continuous delivery with OpenShift

While OpenShift comes integrated with Jenkins, it is also possible to just use the built-in continuous delivery features of OpenShift itself. A build can be configured with triggers based on source code change, registry update, etc which will automatically trigger off a deployment.

OpenShift projects (based on kubernetes namespaces) are isolated, ie, objects residing in one namespace are oblivious to other namespaces unless configured otherwise. This allows us to create logical environments that are separate from each other in the form of namespaces. Thus you could have a project representing your dev environment, another project for test, prod, and so on.

Usually we do not want to let our dev and prod containers running on the same host. Typically we have more powerful and secure hosts for our prod environments than for dev or test. This separation can be done easily using labels and selectors. You label specific nodes as env=dev, env=prod, etc. Then, you can specify a nodeSelector for each of your project and specify the label corresponding to the environment. Once this is done, your dev project's pods will land on your dev hosts and prod pods on prod hosts. Labels and selectors are simple yet powerful, so expect to make use of them a lot.

Organizations that are paranoid about environment isolation can deploy separate OpenShift clusters for each environment, and connect them to a common registry to do continuous delivery across environments. This combined with OpenShift's SDN (software Defined Network) provides robust isolation. Unfortunately you cannot explore a multi-node setup with the CDK environment. You can set that up using the opensource version, or the 30 day evaluation subscription of Openshift Enterprise.

The rise of Kubernetes

It was during the Devopsdays Amsterdam event in June 2015 when I first heard of a new tech in town with a hard to pronounce name, “Kubernetes”. Containers (especially Docker) had just gotten popular around the time, and the problem of managing them at scale was very present. Docker Swarm was found lacking when it came to managing containers spread across number of hosts as in a typical datacenter situation. Google itself had been running containers for a while, and internally working on developing its own container management platform. So in 2015, when Google open-sourced this platform as Kubernetes, it was quickly lapped up by early adopters. Because hey, Google use it so let’s check this out! Kubernetes provides a set of loosely coupled and extensible components which are building blocks to deploy, scale and manage containerised applications. It was a very neat approach in typical Google style that people loved. Kubernetes quickly became one of the most active projects on Github.

Community leverage

In late 2015 Google teamed up with the Linux Foundation to establish the Cloud Native Computing Foundation (CNCF), with the aim to put together an open-source toolkit for cloud-native applications. CNCF focuses primarily on enabling interoperability of these tools, fostering a kind of standard level playing ground for all cloud-native tech. The first project 'adopted' by CNCF was Kubernetes. Since then, it has taken in a number of open-source cloud-native projects into its fold for every space that Kubernetes doesn’t cover (monitoring, logging, service-discovery, etc). By leveraging open-source the expectation is that a commons would emerge that everybody can make use of, and contribute to in order to ensure general welfare, and avoid lock-ins. With Kubernetes, Google has attempted to push the industry towards a certain level of standardisation around container management tech which was absent at the time. The extensibility provided by Kubernetes API makes it possible for any vendor to implement additional functional wrappers around it. This in turn led to the proliferation of containerized PaaS (platform-as-a-service) solutions.

The container platform gold rush

As the world began to adopt microservices and containers, infrastructure software vendors (traditional as well as new ones) came up with their own PaaS offerings built over existing container management tools like kubernetes. They adopt a more developer-centric approach trying to abstract away much of the infrastructure details. In a battle to gain developer mindshare the platforms constantly add built in support for favorite continuous delivery, language-specific build tools, etc, what they call "batteries included". In addition they need to keep up with newer versions of underlying cloud-native toolset like docker and kubernetes which release rapidly. The crowded PaaS space is currently dominated by the likes of Pivotal Cloud foundry, Red Hat Openshift, Rancher, etc.

What's ahead

Into 2017 we are seeing Kubernetes evolve as the defacto standard in the container orchestration space, having grown over 30%, much at the expense of Pivotal Cloud Foundry and Docker Swarm. Almost every major cloud provider (with the notable exception of Amazon Web Services, for now) and most container-based PaaS solutions now run (or support) a Kubernetes based container service. Container platforms which are based on Kubernetes like Red Hat Openshift have the momentum at the moment. More organizations will take leap into cloud-native making use of the plethora of options available. In the meantime they should, look out at shiny new toys like Serverless and CaaS (Container-as-a-Service) that could possibly impact (or disrupt) the landscape.

DevOps value stream

DevOps draws its influence heavily from the Lean movement of the manufacturing industry and the early Agile movement in the IT industry. The book defines the DevOps value stream as the “process required to convert a business hypothesis into a technology-enabled service that delivers value to the customer”. It discusses how we can identify the best technology value streams for our DevOps transformation. The next step is to conduct a value stream mapping exercise which mostly results in an improved understanding of the value stream. It is often possible to re-engineer the process so that we can design a far simpler and more streamlined means to achieving the business goals.

It is often possible to re-engineer the process so that we can design a far simpler and more streamlined means to achieving the business goals.

The Three ways

Our next goal is to apply the Lean principles (also known as The Three ways) to the DevOps value steam:

The principles of Flow – Deployment pipeline, Continuous delivery, Automated testing.

The principles of Feedback – Telemetry, Business monitoring, Enable review processes.

The principles of Continual learning & experimentation – Culture of learning and sharing, Blameless post/pre-mortems.

Of course the book goes into more detail on each of the above topics, and addresses them with equal emphasis on culture and technology.

Integrating Change process, Security and Compliance

A section of the book is dedicated to the often overlooked areas of change management, security and compliance. This expands the scope of DevOps to include InfoSec (Information Security) and change management departments, and prescribes technical practices for the same. A simple example of such an integration, as neatly explained in a case study, would be to move all security issues from a traditional GRC (Governance, Risk and Compliance) tool into a tracking tool. Visible to Dev and Ops, such as Jira, and tag them there according to severity. This makes security issues visible and a responsibility of the team itself.

The succinct nature of the book is very refreshing. A personal favorite is the numerous little case studies strewn all across the book. The authors cite real-world examples to drive home points, rather than just forcing down some theory. We learn about how companies big and small, implemented DevOps to solve grappling problems, ones that are easily relatable. The book covers a lot of ground with brief to-the-point sections, and definitely qualifies to be one of the best treatises available on the subject.

PS: This blog post was published on tmns.com.

People over technology

The overarching theme this time was people and culture. Erica Baker of Slack delivered the keynote themed diversity and inclusion, kicking off a conference with more female participation than seen before. Ken Mugrage of Thoughtworks discussed burnout and other psychological effects of stress. In the talk, he lays out his definition of DevOps:
“A culture where people, regardless of title or background, work together to imagine, develop, deploy and operate a system.”

Cloud-native gaining traction

While last year’s event introduced technologies like Kubernetes, this year’s topics reflected the growing ubiquity of cloud-native architecture and technology. Discussions on real-world challenges such as monitoring of containers, scaling microservices in production and more drew a lot of interest. This is also reflected with the impressive booking growth of top cloud platform vendors like Pivotal and Redhat (both had sponsor booths).

Behavior for High-performance teams

One of the interactive workshops I attended was titled “Creating High-Performance Teams With DevOps Behavior”. This workshop explored what “right behavior” is and how we could positively change the behavior of all stakeholders we interact with. Just like SMART objectives, behavior should be MACRO (Measurable, Active, Controllable, Reliable, Observable). Of course it should pass the Dead Man Test: If a dead man can do it, it ain’t behavior!

Ignite!

The ignite sessions at DevOpsDays are nugget-sized talks of 5 minutes length with 20 slides which auto-advance. This time, I presented an ignite talk where I spoke about Test Driven Containerized Infrastructure. This talk explores how a proven agile technique, – Test Driven Development – can be applied to infrastructure code. This idea of cross-fertilization of best practices was my main motivator to do the talk.

Open Spaces

I can’t talk about DevOpsDays without mentioning Open Spaces. In a nutshell, people nominate topics they would like to learn or share about. Based on interest gauged by a simple show of hands, time slots and locations are assigned. Once scheduled, one is free to attend any open space of choice. The sessions are free form discussions with whoever is present, and there isn’t generally any presenter.

To end, some DevOps trivia

Back in 2009, Patrick Debois and a few like-minded individuals organized the first DevOpsDays conference with the motto “to bring development and operations together”. A large collection of IT professionals converged at Gent, Belgium and the conference generated a great amount of discussion on social media. Debois used a shorter, more memorable hashtag #DevOps, and the movement has ever since been known by this name.

PS: This blog post was published on tmns.com.

Framework selection

A nice selection of node frameworks can be found here. For my application I used the restify module which provides a framework to build 'correct REST webservices'. In other words, it provides for building pure rest api implementation unlike express, which is more of an MVC framework. With resitfy I could decouple the UI and API into separate applications. Node modules, which are basically libraries are available for all kinds of needs.

Angularjs

Angularjs is excellent when it comes to simplifying frontend development. Databinding works like magic, and so are the other innumerous features. The Flatlander store tutorial is a good place to pick up the essentials. Together with Bootstrap you can build pretty and snappy websites easily.

Know your javascript

Of particular importance is Callbacks. Everything in nodejs is asynchronous, ie., the execution carries on without waiting for the results of the current line of code. Callbacks allow you to capture the results of high-response-time functions (like DB actions, LDAP queries, etc) and trigger actions accordingly. Once you get the hang of hit, you will sooner or later end up with something known as Callback hell. And then there is the problem of callbacks within loops. Callbacks are both the boon and bane of javascript. There are better ways to mitigate callback hell, such as with the use of Promises, Generators (only in JS 6), or other frameworks like Rxjs which is based on the Observer pattern.

Application Structure

Structuring the application is an important first step. Best practice is to break down the application into feature modules (subdirectories), and further breakdown each module into controllers, models, views, factories, etc. The wiring can be done via routes, and the various frameworks provides ways to do this. This way of modularizing helps with maintenance as the codebase grows. Recommended practice is to add code in layers as wrappers of more specific implementation.

API design

Modeling the application around logical resources and then using HTTP methods to operate on these resources is the essence RESTful API design. This topic deems much consideration and there is plenty of literature and best practices available.

API discovery/documentation

The use of tools like Swagger allow you to both define your APIs, and automatically generate the stubs, thus letting you focus just on writing the actual functional code. Swagger also generates the API documentation. It is advisable to implement a solution like swagger early on since retroactive fitting can give you a headache.

Authentication & Authorization

If your application consists of stateless API which require some form of user authentication I recommend using JSON Web tokens. JWT is an authentication protocol and using jsonwebtoken we can limit user access to the application. A more comprehensive A&A solution can be implemented using oath2 which is an authentication framework.

Backend

I used the node mongodb driver to connect to my mongo database. Mongoose is another useful mongodb module which many use. My application also required to interface with LDAP for which I used the ldapjs module. As mentioned before there are modules for all kinds of needs and the large node community makes it easy to find solutions on the web.

Test-driven development

TDD is an important agile development principle and Nodejs has built-in assert module to support this. Using a test framework like Mocha in conjunction with nodejs allows developers to write better code.

Continuous delivery

Last but not the least, it is important to plug in any application development exercise to a continuous delivery setup. This includes your usual suspects: source code repo, a dockerized application build and deployment setup, automated testing, etc. Again this topic deserves its own blog post.