I’m offering a two-day, intensive, hands-on training course at the upcoming O’Reilly Software Architecture Conference in Boston, MS. The class is entitled Cloud-Native Application Architectures with Spring and Cloud Foundry. In this class you will have the opportunity to implement an easy-to-understand storefront system (complete with product search, details, reviews, and recommendations) as a cloud-native architecture using Spring and Cloud Foundry. In addition, you’ll get hands-on exposure to the Netflix OSS family of technologies.
This article was originally published in the April 2014 issue of NFJS the Magazine. This article begins an introductory series on the Go programming language. Go is a language optimized for large-scale software engineering and is rapidly becoming the language of choice for building cloud services. It does this in a very interesting way, optimizing for simplicity rather than complexity and taking a “less is exponentially more” approach.
I’ve started curating a Microservices Reading List. It’s still work in progress, but there’s some good stuff there. Watch for more!
Microservices are often described as small, loosely coupled applications that follow the UNIX philosophy of “doing one thing well.” They have also been related to the Single Responsibility Principle, the first of the five principles making up SOLID. A microservices-based architecture is typically constructed around a set of common patterns. This set of patterns is actually consistent with all of the SOLID principles when thought of at the architectural rather than the class/module level.
The gauntlet has again been dropped in the world of cloud interoperability. The dueling factions include those asserting that competitors to Amazon’s web services (principally OpenStack) must adopt AWS’s API’s in order to remain viable, and those that believe such “API cloning” will do nothing more than stunt innovation. If you were to ask me, I’d say that we’ve seen this play out before. Remember the “Clone Wars” that began in the late 1980’s and that persisted for the better part of two decades?
One of the great things about Cloud Foundry is that it is a great enabler. Tall words. But what do they mean? Essentially, Cloud Foundry (and any other well-designed PaaS) enables us to do things as developers and operators that would be extremely difficult in a traditional deployment environments. One particularly valuable area of enablement is our new found ability to practice Continous Delivery, meaning that we continuously prove our ability to deliver working software by continuously treating each code commit to a system as if it could be deployed to a production environment.
I was inspired by Brian McClain’s post on bringing Haskell to Cloud Foundry using Cloud Foundry v2 buildpacks, so I decided to go on a buildpack journey of my own. Since Clojure is the language I most enjoying “toying around with,” I thought I’d try to deploy a simple Clojure web application using the Heroku Clojure Buildpack. To reiterate some of the coolness around buildpacks, they are what allows a PaaS like Cloud Foundry or Heroku to support various runtimes without first building that support into the core platform.
Wow…it seems I only post to this blog toward the end of May. Well, that all changes now. You see, as of June 3, 2013, this blog is going to become one of many aspects of my new “day job.” On Monday, I start my life as a Community Engineer with Cloud Foundry by Pivotal. What’s a Community Engineer? Quite honestly, I’m not completely sure of the answer to that question yet.
I have rebooted this blog many times over the last several years. If you’ve been a reader of my blog in the past, you will have noticed significant changes. If you’re new here, welcome! This reboot has been in the works for several months now, even though I’ve probably spent far less than 24 active hours working on it. Life as an “itinerant” consultant and conference speaker is extremely busy compared to what I was doing on May 16, 2012 (the date of my last blog posting).
For those of you that don’t know, I recently returned to the technical ranks as a Software Architect after a three-year stint in management. To make a long story short, I now love my job again. Perhaps I’ll write the long story in a future blog entry. On to the topic at hand. Today I led the first significant design discussion that I have led in quite a long time. A few minutes afterward, I was already reflecting on what had occurred and how.