PaaS, Microservices, SMAC and Digital helps your company to react quickly
A couple of months ago, I’ve started playing around with some PaaS software implementations, to evaluate alternatives in effective continuous deployment’s discipline.
Baby-steps understanding
First things first: for better PaaS understanding, follow this two different scenarios we face almost every day:
These are the two best metaphor I’ve ever seen, useful enough to expose differences from IaaS, PaaS and SaaS to non-technical stakeholders, by using practical examples comparing types of hosting.
Bringing this same comparison to real software hosting, we have a clear separation among on-premise, IaaS, PaaS and SaaS.
More recently, another new branch in software hosting is raising, but I’m not going to detail in this article. You can check it: MBaaS/BaaS.
PaaS background: how we got here?
At some point in the past, old-school people often produce and vertically scale monolithic software, in self-hosted data centers, replicating and mirroring WARs and EARs (J2EE projects) packages in several expensive, huge, multi-application containers applications servers (e.g. Oracle Glassfish, Apache Geronimo, IBM WebSphere, WildFly, ObjectWeb JOnAS, etc), putting a network load balancer (virtual IPs) in front of it’s traffic load. Servers used to have a bunch of memory, powerful processors, as well as speedy hard disks.
In the other hand, software development process engineering tells nothing about how to deploy and maintain a software production architecture. Usually, people who develops software knows nothing about production servers as well as sysadmins knows nothing about applications.
The consequence is companies with lots of people to manage network, servers, resources and production environment, working hard to keep things up and running, while developers delivers features at end of a development time window, and need the features working in production.
And of course, errors occur, and the same people who maintain production environment, also replaces memories cards as well as bare-metal hard-disks.
Eventual blackouts were expected and accepted as a normal event of a deployment cycle. Post-midnight work scheduling maintenance was expected as well and broadly adopted. Unfortunately, it still happens, in lots of companies.
There was hard times, you better believe me. Well, people moved on. They started with IaaS.
Infrastructure as a Service — IaaS
At some point not so long past, 2006, Amazon released EC2 machines, so you could handle infrastructure as a services in so many different ways. Concurrently, other vendors released VPS as well (2012, Google Cloud Compute Engine; 2011, Digital Ocean; 2012, Azure; etc). Amazing people from packaging services, like Bitnami, TurnKey and AMPPS helped developers to assembly production-ready environments easily.
Platform as a Service — PaaS
At recently past, 2011, even with IaaS facilities, Heroku decided to deliver their own PaaS software upon AWS infrastructure, so, developers could deliver software quicker, without worrying manual provisioning. Heroku has provisioning capabilities that leverages software deployment and turned continuous deployment pipelines just simple.
Heroku can manage several languages, and provides several managed addons (+150, free and paid), working in a transparent way of infrastructure management. Nowadays is Git-centric, starting build pipeline through git push command.
So, people started to developing open-source alternatives to Heroku: Flynn, OpenRuko, OpenShift, DEIS, Cloudify, Apache Stratos, Empire and more recently, endorsed by Globo.com, Tsuru.
With PaaS, the persona of DevOps raised from background of infrastructure, and starts to play a large role in development cycle: that guy who knows about applications needs, and who knows about what platform offers and can push the “play” button, that starts the application. This same guy knows nothing about infrastructure provisioning, networks and monitoring.
From all opensource alternatives above, IMHO, brilliant people built the DEIS (day-iss) platform. It was first release at 2013. It’s a Heroku-style PaaS and with at least three instances of Core OS system, allowing you to create your own PaaS environment. DEIS endorse self-hosting as on-premise software, as well as engage IaaS vendors to their deployment needs. Nowadays, DEIS Workflow brings Kubernetes to infrastructure provisioning.
Parallel to Heroku people, Pivotal and a group of companies has built CloudFoundry, and delivered among others, IBM BlueMix Platform.
CloudFoundry is a powerful and complex PaaS, feature-full, deployed by several providers.
As well as DEIS’s people, to minimize effort of trying Cloud Foundry in a local development environment, Pivotal decided to publish Lattice, an steroids-free PaaS software.
Using Lattice means you should assembly you own Docker images under Docker Hub, which IMHO is a big disadvantage. Not having a container engine to assembly images directly from a local repository, means you should have a DockerHub account, which have limitations in private repositories.
In terms of CloudFoundry, you can try online (60-days free trial) at Pivotal Web Services.
Personnel PaaS, with batteries included
At some point of nowadays, 2013, DEIS people decided to deliver a fat-free DEIS style PaaS, keeping batteries-included, called Dokku.
The main purpose is to allow the developers to test the software for PaaS environment and reduce the impedance of developing cloud-ready software. As you might know, developing cloud-ready software should be sightly different from developing desktop software. The best guide to follow about developing cloud-ready applications is 12-factor manifesto.
For freelancer developers, Dokku means a great advantage, since DigitalOcean endorses people renting a $5 bucks droplet and deploying their own private PaaS, controling absolutely everything locally.
Well, we can easily ship software now
In fact, there are plenty of new companies and hard supporters of agile software development, with great developers and DevOps, working hard to make things happen in PaaS strategy.
For instance, Github (not as a git repository, but as a company) is a great example of how a deployment should not be an event, and should not involve people, at least, not directly:
Shipping almost 200 deploys per day means absolute control over continuous delivery.
Shipping Titanic
Well, it is really good to remember that developing software in a PaaS approach has a lot of limitations in terms of old-school infrastructure management, but it does leverages developers and DevOps experience, as well as suits incredible good into sysadmins hands.
Even having PaaS without worring about infrastructure, should we deploy large software’s pieces everytime? Or, should we break into smaller pieces, granting minor effort in each deployment?
About Microservices: how we got here?
PaaS and Microservices’s concepts and practices should be highly tied and coupled (IMHO). You might have a PaaS environment when you need deploy quickly, easy and continuously, however, monolithic’s software architecture might block your delivery flow!
You must be aware that deploying a PaaS environment worth nothing without an agile software development flow, an value engineering prioritization as well as a inner community spirit established and scattered with developers, product owners and product’s sponsors.
Microservices: buzzword to an old practice
Sam Newman makes a good approach on his book, arguing that breaking large software parts into smaller is a very old concept, as we bring it from old CORBA and DCOM.
In this way, microservices are not a shinning new thing. What we are calling of microservices today is a rescue of old-school software engineering techniques and best projects practices, very explored long way before, but with a fresh global engagement and great players delivering great frameworks (as Netflix OSS does), and great agile’s process tools.
Additionally, now we have flexibility and diversity in terms of high-level languages (4GL) and specialized frameworks. We also have the advent of cloud computing and cheaper hardware infrastructure.
It’s all about fail fast, measure precisely and react properly
Decoupling all software parts raises ability of a product’s company react properly, quickly and precisely, by metrics unveiling general public adoption of a certain feature.
Balancing what should be decoupled and discover the best rule to partition a product might follow this cube, as software architect and product owner decides together which is more important to partition: data, functional or even performance.
You might analyse the product’s phase to decide whether where you should go is monolith or microservices, and more important: how fine grain you should build the software and how often you must deliver and measure adoption.
It’s absolutely reasonable argue that there’s no silver bullet for product success or which is better of monolith and microservices approach.
Also, since one size does not fit all, you better validate the maturity of software development process, of your team skills and your infrastructure volatility.
Going microservices approach involves lots of governance needs because your code will duplicate, your teams will stop talking to each other, features will be re-implemented across teams, internal subproducts REST API will deprecate, people will depend on your microservice and your microservices will not activate any value if any other dependency needed are unfinished.
As soon as you decide how size is your microservice, and how mature your team is to move on, developers will build and ship them, so you might have a DevOp to help your team to deploy.
DevOps to the rescue
Daniel Bryant wrote a great article about modern J2EE software development, endorsing that PaaS, DevOps and microservices are made each other.
Helping developers to deploy and accomplish software components, means DevOps in top of microservices deployment, in terms of having a DevOp dedicated to a group of microservice (so he can specialize into the business) and Devs requiring more platform, plugins and scale to DevOp, as following:
Nonetheless, even if you break your software into smaller parts, and even you have good DevOps and Developers aligned, building and shipping software parts continuously, is your product ready for competitors?
Is your company ready to be as social as your consumers needs? Are you company prepared to analyse feature adoption or even consumer complaints? Even in social networks?
Are your application ready for mobility and ubiquity? Are your application ready for omnichannel communications?
Going Digital
Personally, microservices, PaaS and DevOps are very straight forward concepts and also, I see constantly another enforcement in companies: their core business are changing from a specific market share to something new, near from software, technologies, web and performance.
The point is using technology not as an end point to reach some place in future, but as a means of transportation to get somewhere better and more significant in market.
There isn’t another way of biting other players without working with technology and digital innovation, since their local or regional business gets susceptible to online competition.
For instance, lots of companies are not recognized as just retails players, but nowadays, they are behaving like technology companies, and their IT and Software Engineering departments are not just as help-desk support, but as core business that impact directly in theirs net revenues and partnerships. This is what’s happening at Walmart.com, Amazon, Oak, NuBank as well as other companies.
Disrupting innovation and SMAC
The movement about Digital Disrupting and SMAC (Social, Mobile, Analytics and Cloud), is leveraging companies to a higher technological degree, turning enterprises in a tech-centric fashion.
I did a benchmarking into Digital Disruption and SMAC, presenting what software vendors are working on Digital Disruption and what their customers are building. You can check it out here.
We are currently watching a practical example of innovation and just-in-time adaptability: Facebook, Uber, AirBnB, and Alibaba as largest companies in the world in their own segments, just by social success, without having lawful assets, or spending money endorsing themselves by their market share they are embedded.
Uber has no cars, AirBnB has no accommodation, Facebook produces no media, and so on. Even with no assets, they are massive leaders.
IMHO, this kind of trend moves companies and makes they see beyond their core business.
Move on
Companies should use cutting-edge technologies, microservices, DevOps, PaaS, Disruptive Innovation, SMAC and Digital to help them to fail often and fast. To perceive whats is doing right and what should be discontinued.
Enterprises must balance and endorse what is generating early users adoption, and have capabilities to change direction any time needed, without worry about impedance on changing direction on software architecture or business model. Just measuring what customers accepts and what does not generate revenue.
