TL;DR

Modern Apps use Platforms, Continuous Delivery, and Modern Languages.

Or more specifically, Modern Apps are written in Modern Languages, get deployed onto Platforms, and that deployment process is Continuous Delivery (as these things are all interconnected).

Background

‘Modern Apps’ seems to be a hot topic right now. Some of my DXC colleagues are getting together for a workshop on Modern Apps next week (and this will be pre-read material). Our partner VMware launched its Modern Applications Platform Business Unit (MAPBU) this week, which brings together its acquisitions of Heptio and Pivotal. But it seems that many people aren’t too clear about what a Modern App actually is – hence this post.

Modern Apps use Platforms

Modern Apps are packaged to run on platforms; and the packaging piece is very important – it expresses a way by which the application and its dependencies are brought together, and it expresses a way by which the application and its dependencies can be updated over time to deal with functional improvements, security vulnerabilities etc.

It seems that the industry has settled on two directions for platforms – cloud provider native (and/)or Kubernetes:

Cloud Provider Native

‘Cloud Native’ is a term that’s become overloaded (thanks to the Cloud Native Compute Foundation [CNCF] – home of Kubernetes and its many members); so in this case I’m adding ‘Provider'[0] to mean the services that are native to public cloud providers – AWS, Azure, GCP.

And mostly not just running VMs as part of the Infrastructure as a Service (IaaS). For sure it’s possible to build a platform on top of IaaS (hello Netflix and Elastic Beanstalk etc.).

And not just the compute services, but also the state management services, whether that’s for more traditional relational databases, or more modern ‘NoSQL’ approaches whether that means key-value stores, document or graph databases, or something else.

The use of cloud native also implies that apps are composed from a set of loosely coupled services that connect together through their Application Programmer Interfaces (APIs). In general we can also expect an app (or group of apps working on the same data) to run on a single cloud provider, because of the economics of data gravity.

Kubernetes

In just over 5 years since its launch at the first DockerCon it seems safe now to say that Kubernetes has won out over the panoply of other platforms. Mesos, Docker Swarm and Cloud Foundry all took their swing but didn’t quite land their punch.

There’s definitely some overlap between Kubernetes and Cloud Native as defined above (particularly in Google’s cloud, where arguable they’ve been using Kubernetes as an open source weapon against AWS’s dominance in VM based IaaS). But in general it seems people choose Kubernetes (rather than cloud native) for its portability and a sense that portability helps avoid lock in[1].

Portability means that something packaged up to run on Kubernetes can run in any cloud, but it can also run on premises. For those who determine that they can’t use public cloud (for whatever reasons) Kubernetes is the way that they get the cloudiest experience possible without actual cloud.

There’s a lot of scope for internal platform engineering teams to get themselves into trouble building something out of Kubernetes (which is addressed very well by Forrest Brazeal in his ‘Code-wise, cloud-foolish‘ post), but I’m expecting VMware (with Tanzu) and Google (with Anthos)[2] to take care of that stuff so that enterprises don’t have to.

Modern Apps use Continuous Delivery

Or maybe even Continuous Deployment, but mostly Continuous Delivery (CD), because not many organisations aren’t ready yet to have code changes flow all the way into production without at least one manual step.

CD pipelines provide a connective tissue between ever changing user need, and the platforms that apps are deployed onto.

CD pipelines also embody the tests necessary to validate that an application is ready for a production environment. For that reason Modern Apps are likely to be written using techniques such as Test-driven Development (TDD) and Behaviour-driven Development (BDD).

Of course there will be times where the test suite is passed and things make their way into production that shouldn’t, which is a good reason to make use of Progressive Delivery techniques and Observability.

Continuous Delivery implies DevOps

Pipelines run across the traditional Dev:Ops lines within an organisation, so running Modern Apps mean going through organisational change. DevOps Topologies does a great job of illustrating that patterns that work (and the anti-patterns that don’t).

It’s no accident that the operational practices of Site Reliability Engineering (SRE) evolved within Google at the same time as they were building and moving to their Borg Platform.

Modern Apps use Modern Languages

Or at least modern frameworks for some of the older languages – there’s a whole ton of Java still being written, but there’s a world of difference between the Enterprise JavaBean (EJB) centric world of Java 2 Enterprise Edition (J2EE) and today’s Spring Boot apps.

The RedMonk Programming Language Rankings (June 2019 edn) provide a good guide, if you can ignore C++, C and Objective-C, as popularity doesn’t equate to modernity. There’s also the Programming languages InfoQ Trends Report (October 2019 edn), which charts languages on a maturity curve:

and might be polyglot

Monolithic apps imply a single language; but the rise of microservices architecture comes about in part by empowering developers to choose the right languages and frameworks for their piece of the overall puzzle.

but doesn’t have to use a Microservice architecture

‘Microservices are for scaling your engineering organisation, not your app’ is how Microservices pioneer Adrian Cockcroft puts it, which is one of the reasons why Microservices is not a defining feature of Modern Apps.

It’s perfectly OK to have a small monolith developed by a small team if that’s all it takes to satisfy the business need. Per John Gall:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.


A service provider view

Most of the discussion on apps centres on in house development, and the notion of ‘you wrote it, you run it’ is central to the operations philosophy within many organisations.

But looking at the application portfolio of most DXC customers there’s typically very few in house applications (and hence not very much ‘you wrote it, you run it’).

For sure there’s a bunch of apps that service providers like DXC (and Luxoft) and our competitors build (and run); but there’s also a ton of packaged apps (aka commercial off-the-shelf – COTS) that we run the infrastructure for.

There’s been a general shift away from on premises packaged apps to SaaS for CRM (e.g. Siebel to Salesforce), HR (e.g. Peoplesoft to Workday) etc. But there are still the cloud refusniks, and there are still many Independent Software Vendors (ISVs) selling stuff into the mass market and down to various niches. Just as virtualisation drove a shift from scripted installers to virtual appliances, we can expect to see another shift towards packaging for Kubernetes.

As we look forward to a world more defined by Application Intimacy, the work of service providers will be less about running the infrastructure (which is subsumed by the platforms), and more about care and feeding of the apps running on those platforms.


Bonus content

Platform History

Both Cloud Foundry and Kubernetes trace their roots back to Google and its Borg platform.

Cloud Foundry came from Xooglers Derek Collison and Mark Lucovsky during their time at VMware (before it was spun off into Pivotal), and the BOSH tool at its heart is a homage to Borg (BOSH == borg++).

Meanwhile Kubernetes came from within Google as a way of taking a Borg like approach to resource management applied to Linux containers that had been popularised and made accessible by Docker (which built on the work the Googlers had put into the Linux kernel as cGroups, Kernel capabilities and Namespaces on the way to making Linux and Borg what they needed).

It’s therefore well worth watching John Wilkes’ ‘Cluster Management at Google‘ as he explains how they manage their own platform, which gives insight into the platforms now available to the rest of us.

Of course platforms existed long before Borg, and the High Performance Computing (HPC) world was using things like the Message Passing Interface (MPI) prior to the advent of commercial grid computing middleware. What changed in the last decade or so has been the ability to mix compute intensive workload with general purpose (typically more memory intensive) workload on the same platform.

Heroku deserves a mention here, as one of the early popular Platforms as a Service (PaaS). The simplicity of its developer experience (DX) has proven to be an inspiration for much that’s happened with platforms since.

12 Factor

Modern Apps probably should be Twelve-Factor Apps:

  1. Codebase One codebase tracked in revision control, many deploys
  2. Dependencies Explicitly declare and isolate dependencies
  3. Config Store config in the environment
  4. Backing services Treat backing services as attached resources
  5. Build, release, run Strictly separate build and run stages
  6. Processes Execute the app as one or more stateless processes
  7. Port binding Export services via port binding
  8. Concurrency Scale out via the process model
  9. Disposability Maximize robustness with fast startup and graceful shutdown
  10. Dev/prod parity Keep development, staging, and production as similar as possible
  11. Logs Treat logs as event streams
  12. Admin processes Run admin/management tasks as one-off processes

But let’s just acknowledge that the 12 Factors might be aspirational rather than mandatory for many Modern Apps in real world usage.

HTTP or messaging based?

The web has made the HyperText Transfer Protocol (HTTP), and its more secure version HTTPS ubiquitous, especially as most firewalls have been configured to allow the easy passage of HTTP(S).

But HTTP is synchronous, and unreliable, which makes it a terrible way of joining things together.

Developers now have a bunch of choices for asynchronous (and sometimes reliable) messaging with protocols like AMQP, MQTT, NATS[3] and implementations such as RabbitMQ and Apache Kafka.

REST

The uphill battle here for messaging is that in the wake of heavy weight Service Oriented Architecture (SOA) defined by protocols like SOAP and WSDL, respresentational state transfer (REST) became the de-facto way of describing the APIs that connect things together, and it’s very tightly bound to HTTP methods.


Notes

[0] Thanks to my colleague Eric Moore for providing the suggestion of ‘Cloud Provider Native’ as a better label than just ‘Cloud Native’ (see thread on LinkedIn for background).
[1] Some wise words on this topic from OpenStack pioneer Randy Bias ‘You Are Locked In … Deal With It!‘ and from Gregor Hohpe on Martin Fowler’s blog ‘Don’t get locked up into avoiding lock-in‘ that now seem to have found their way into UK government guidance – ‘Managing technical lock-in in the cloud
[2] See Kubernetes and the 3 stage tech maturity model for more background
[3] Derek Collison pops up here again, as NATS came from his efforts at Apcera to build a better enterprise PaaS than Cloud Foundry. Collison has deep experience in the messaging space, having worked on TIBCO Rendevous and later their Enterprise Message Service (EMS), which he reflects on along with the origins of Cloud Foundry in this Twitter thread.


Andrew “bunnie” Huang recently presented at the 36th Chaos Communication Congress (36C3) on ‘Open Source is Insufficient to Solve Trust Problems in Hardware‘ with an accompanying blog post ‘Can We Build Trustable Hardware?‘. His central point is that Time-of-Check to Time-of-Use (TOCTOU) is very different for hardware versus software, and so open source is less helpful in mitigating the array of potential attacks in the threat model. Huang closes by presenting Betrusted, a secure hardware platform for private key storage that he’s been working on, and examining the user verification mechanisms that have been used in its design.

Continue reading the full story at InfoQ.


TL;DR

We can model data gravity by looking at the respective storage and network costs for different scenarios where workload and associated data might be placed in one or more clouds. As network egress charges are relatively high, this makes the effect of data gravity substantial – pushing workloads and their data to be co-resident on the same cloud.

Background

Dave McCrory first proposed the idea of Data Gravity in his 2010 blog post ‘Data Gravity – in the Clouds‘:

Consider Data as if it were a Planet or other object with sufficient mass.  As Data accumulates (builds mass) there is a greater likelihood that additional Services and Applications will be attracted to this data

He finishes the post with ‘There is a formula in this somewhere’. This post will attempt to bring out that formula.

More recently

The 451 Group’s cloud economist Owen Rogers wrote a report almost a year ago titled ‘The cloud bandwidth tax punishes those focused on the short term’ (paywalled), where he explored the interactions between storage cost and bandwidth cost.

As I noted in The great bandwidth swindle cloud providers are using egress charges as an economic moat around their services. It makes data gravity true.

Owen’s report contains a simple model charting access frequency against storage period to determine a heat map of bandwidth contribution to total cost, and it’s a very hot map, with much of the surface area past 50%.

With thanks to Owen Rogers at The 451 Group for allowing me to use his chart

The emerging message is simple – once your data is in a cloud storage is very cheap relative to the cost of getting the data back out.

The corollary is also alluringly simple – data gravity is real, so you should put all of your data (and associated workload) into the same cloud provider.

Variables

We typically refer to compute, storage, and network when talking about systems, so let’s use the variables cs, and n respectively.

Duration

c is usually billed by the hour, though the resolution on usage might be down to the second for IaaS or by a number of invocations for FaaS (with CaaS and PaaS dropping somewhere in between on the spectrum).

s is usually billed by the GB/month

n is usually billed by the GB

Most clouds present bills on a monthly basis, so it makes sense to evaluate over that duration, and allows us to build realistic scenarios of how c, s & n combine to a total bill (b).

The basic equation

b = c + s + n

Simple enough, the monthly bill is the sum of compute, storage and network egress costs, which is pretty uninteresting.

Two clouds

This is where it gets interesting. It could be two regions in the same cloud provider, two different cloud providers, or the oft discussed hybrid of a public cloud and a private cloud. The gross mechanics are the same, but the scaling factors may vary a little.

b = c1 + s1 + n1 + c2 + s2 + n2

Again, this seems simple enough – the monthly bill is just the sum of compute, storage and network egress used across the two clouds.

Base case – independent applications

Where the apps deployed into cloud 1 and cloud 2 have no interaction there’s really nothing to consider in terms of the equation above. We can freely pick the clouds for reasons beside data gravity.

Case 1 – monthly data copy

Scenario – the transactional app in cloud1 generates 100GB of data each month that needs to be copied to the reporting app in cloud2

Assumption 1 – compute costs are roughly equivalent in cloud1 and cloud2, so we’ll ignore c1 and c2 for the time being, though this will give food for thought on what the delta between c1 and c2 needs to be to make it worth moving the data.

Assumption 2 – the output from the reporting app is negligible so we don’t run up egress charges on cloud2

Assumption 3 – once data is transferred to the reporting app it can be aged out of the transactional app’s environment, but the data is allowed to accumulate in the reporting app, so the storage cost goes up month by month.

Taking a look over a year:

b1 = $2.5 + $9 + $2.5 +0
b2 = $2.5 + $9 + $5 +0
b3 = $2.5 + $9 + $7.5 +0
b4 = $2.5 + $9 + $10 +0
b5 = $2.5 + $9 + $12.5 +0
b6 = $2.5 + $9 + $15 +0
b7 = $2.5 + $9 + $17.5 +0
b8 = $2.5 + $9 + $20 +0
b9 = $2.5 + $9 + $22.5 +0
b10 =$ 2.5 + $9 + $25 +0
b11 = $2.5 + $9 + $27.5 +0
b12 = $2.5 + $9 + $30 +0

by = 12 * $2.5 + 12 * $9 + 12 * ((12 + 1) / 2) * $2.5 = $30 + $180 + $195 = $405

In this case the total storage cost is $225 and the total network cost is $180, so network is 44% of the total.

Refactoring the app so that both transactional and reporting elements are in the (same region of the) same cloud would save the $180 network charges and save that 44% – data gravity at work.

Case 2 – daily data copy (low data retention)

Scenario – the modelling app in cloud1 generates 100GB of data each day that needs to be copied to the reporting app in cloud2

Assumptions 1 & 2 hold the same as above

Assumption 3 – the reporting app updates a rolling underlying data set

b = $2.5 + $270 + $2.5 + 0

by = 12 * $2.5 + 12 * $270 + 12 * $2.5 = $30 + $3240 + $30 = $3300

In this case the total storage cost is $60 and the total network cost is $3240, so network is 98% of the total. The Data Gravity is strong here.

Case 3 – daily data copy (high data retention)

Scenario – the modelling app in cloud1 generates 100GB of data each day that needs to be copied to the reporting app in cloud2

Assumptions 1 & 2 hold the same as above

Assumption 3 – the reporting app keeps all data sent from the modelling app

b1 = $2.5 + $270 + $37.5 + 0

b12 = $2.5 + $270 + $862.5 + 0

by = 12 * $2.5 + 12 * $270 + 12 * 30 * (12 / 2) * $2.5 = $30 + $3240 + $5400 = $8670

In this case the total storage cost is $5430 and the total network cost is $3240, so network is down to 37% of the total, which is still pretty strong data gravity.

Conclusion

We can build an economic model for data gravity, and it seems to be sufficiently non trivial to lead to billing driven architecture, at least for a handful of contrived use cases. Your mileage may vary for real world uses cases, but they’re worth modelling out (and I’d love to hear the high level findings people have in comments below).


This isn’t a new thing. I’ve even written about it before. But it seems to be coming up in a LOT of conversations at the moment.

The price that cloud providers charge for egress from their networks to the Internet is staggeringly high.

Or as Bryan Cantril put it in a recent episode of his On the Metal podcast:

Rapacious bandwidth pricing[1]

It’s an industry wide problem

I’ll use a bunch of AWS examples, but this isn’t just an AWS problem (even if arguably they started it).

If I look at egress to the Internet from respective US-East regions then the cost per GB for the first TB of data works out as:

  • AWS $89.91 (first GB is free then $0.09 per GB)
  • Azure $86.57 (first 5GB is free then $0.087 per GB)
  • GCP $120 ($0.12 per GB)

The VPS comparison for saner pricing

Since before Infrastructure as a Service (IaaS) came along it’s been possible to rent a virtual private server (VPS) from hosting companies. AWS even has an offering in the VPS space these days with Lightsail.

The cheapest Lightsail bundle is now $3.50/month and includes 1TB of data[2].

Putting together that bundle from its parts for a 30 day month would cost:

  • 1 vCPU and 512MB RAM (t2.nano instance) $4.176
  • 20GB EBS $2.00
  • 1TB data egress $89.91

Clearly Lightsail is a bargain when compared to the equivalent EC2 instance just on compute and storage, but it’s a total bargain when egress charges are considered[3].

In the beginning

There’s no mention of network pricing in the EC2 Beta launch post, just “250 Mb/second of network bandwidth” within the $0.10 an hour bundle that included a 1.7GHz vCPU, 1.75GB of RAM and 160 GB of local disk.

Egress pricing first comes up in the March 2006 press release announcing S3, which states that “Developers pay just $0.15 per gigabyte of storage per month and $0.20 per gigabyte of data transferred”.

Early pricing is understandable

When AWS launched S3 and EC2 they weren’t a huge chunk of overall Internet traffic like today, so it’s reasonable to expect that they were having to pay carriers for egress and needed some way to pass those costs on to customers.

Prices have come down over time

But not as quickly as CPU and storage.

After the launch price of $0.20 there are posts from 2008, 2010, and 2014 announcing transfer price reductions. The latest pricing seems to have been in place since 2017:

Bandwidth has come down between 2.2x and 4x since launch.

For comparison the $0.10 that bought an m1.small at launch now gets an m5.large with 8x the CPU and over 4.5x RAM.

Or the $0.15 that bought 1GB of S3 in 2006 now gets 6.5x more storage.

Present pricing seems harder to justify

The cloud providers don’t pay carriers to get data onto the Internet any more. To a first approximation their networks ARE the Internet.

Going past the VPS comparison above it’s possible to find VPS on LowEndBox with 1 TB of transfer per month for $16.99/yr – that same bandwidth with EC2 would be $1078.92 (or 63x more expensive).

This isn’t about being a few % out of whack, it’s a couple of orders of magnitude (especially when considering that cloud providers are paying far less for connectivity than smaller VPS providers)[4].

Asia Pacific is even more expensive

I’ve used number from US-East, and pricing varies by region, with Asia Pacific being substantially more expensive. In relative terms that’s understandable given the underlying costs of undersea fibre links. In absolute terms it’s the same story as above.

Why do the cloud providers keep doing this?

On one hand customers don’t really have a choice – in the confusopoly that’s cloud it seems that all of the providers are charging much the same for data egress.

On the other hand the egress charges are what keeps data and the services around it on a particular cloud – it’s a protective moat, which explains why none of the cloud providers seem in any hurry to initiate a price war on this line item. I’m planning to write more on the topic of data gravity and cloud economics in due course – so this is just laying some foundations.

Conclusion

IaaS data egress charges are excessive in comparison to VPS transfer pricing, which right now provides a high margin revenue stream for the cloud providers (and some nasty bill shock for their customers[5]).

Those charges also bear upon the data gravity for each provider. When McCrory coined the term he noted ‘there is a formula in this somewhere’, and that should be quantifiable by looking at the relationship between storage costs (for data at rest) and transfer costs (for data in motion).

Update 10 Jan 2020

The Register had a piece in 2018 saying it was a ‘Great time to shift bytes: International bandwidth prices are in free fall‘ noting that a 10 Gbps link from New York to London cost $5000/month (which isn’t directly comparable to Internet transit cost, but illustrates the ball park). Back in 2014 Cloudflare founder and CEO Matthew Prince noted that transit in North America was coming out at $10/Mbps in ‘The Relative Cost of Bandwidth Around the World‘, which was updated in 2016 in ‘Bandwidth Costs Around the World‘.

Update 21 Jan 2020

Corey Quinn has a whole episode of his AWS morning brief on ‘Data Transfer Pricing

Somehow AWS has managed to successfully convince an entire generation of companies that bandwidth is a rare, precious, expensive commodity.

Unless it’s bandwidth directly into AWS from the internet.

Notes

[1] Bryan’s last company Joyent charged the same rates for bandwidth as AWS.
[2] Lightsail data is metered in and out, but then for a typical web server most of the data is out, so this isn’t a true apples to apples comparison, but should be pretty close for most cases.
[3] There’s a catch lurking here. Most hosting providers will just cut off your VPS once all the bandwidth allocation has been used, which can be terrible for user experience but at least doesn’t have an economic impact. That’s not how things work with Lightsail, which instead has ‘overage charges’, which are the same as EC2. So if you’re running a site that does 3.5TB a month then it’s better to pay for the $20 bundle that comes with 4TB than go with the $10 bundle that comes with 3TB then run up a $45 overage.
[4] There is an argument here that cloud providers have much more reliable networks (and services in general) than the VPS providers, but that doesn’t seem to counter the economy of scale argument.
[5] Providers don’t just charge for egress. There are also charges for transfer between zones in the same region, transfer between regions etc. Cloud Economist and Last Week in AWS newsletter curator Corey Quinn has an infographic with the full run down.

 


This question came from a colleague, and it’s one of those questions that I’m surprised and saddened that we still have to ask.

My history with this stuff

Some 15 years ago I was a beta tester for Leslie Muller‘s ‘Virtual Developer Environment’ (VDE)[1], which was a web site that let me request a virtual machine (VM). I’d fill in a simple form, and about 8 minutes later I’d get an email with connection details for my VM.

There’s a technical aspect to this

It took 8 minutes to provision a VM because that’s how long it took to copy the bytes from the golden image on a file share to the VM server.

When shadow volume copy technology came along on modern storage systems that copy time went away, and it was possible to get VMs as quickly as they could boot (which is a few seconds for a reasonable machine image on reasonably fast storage).

So technically the time to provision a VM is somewhere between a few seconds and a few minutes; and that’s been true for the whole time we’ve had VM provisioning systems.

And there’s an organisational aspect to this

Provisioning a VM takes resources – CPU, RAM, storage, and resources cost money, and organisations like to control how they spend money.

If an organisation makes an up front decision to spend money on VMs for a certain purpose that can be bound into the provisioning process then there’s no good reason why VMs can’t be provisioned in seconds to minutes per the technical constraints above.

This is why public cloud is fast, because the decision to spend money has already been made. That decision might be implicit, but it nevertheless has been taken. Public clouds have also done some cool stuff behind the scenes to make provisioning fast (e.g. by having a pool of Windows servers pre provisioned waiting for users[2]).

If on the other hand an organisation decides to embed the spending decision as an approval workflow that presents as part of the request process for a VM then it can take a while (days to weeks) because it’s no longer a straight through automated process, but instead something waiting on (multiple) human interactions[3].

There can be further technical hurdles

The CPU, RAM and storage needed for a VM can be contained reasonably elegantly into the virtual server infrastructure (pretty much irrespective of how that’s put together). But the observant will have noticed that network is missing from that list, and VMs need things like IP addresses and DNS names.

Of course that stuff can be completely automated with things like DHCP, but many organisations have rules against that sort of thing (because some time in the mid 90s some nugget managed to exhaust a DHCP table by setting the lease duration too long or similar foolishness).

If IP addresses come from Fred’s IP address spreadsheet, then the provisioning process will bottleneck there. If server names come Tina’s tombolla, then the provisioning process will bottleneck there too.

IP Address Management (IPAM) has emerged as a product category that fits the dark arts of legacy enterprise practices into tool suites, that can then be more or less integrated into automated provisioning, so there are ways of holding on to the policy debt of past approaches whilst still working with more modern needs.

Quotas and leases

It’s worth reflecting how we dealt with the spending approval in the early days of VDE.

Each department bought an allocation of capacity (usually in units of servers), and from that capacity they could hand out quotas to users. The main constraint was (and generally remains to this day[4]) RAM, so the quotas were RAM quotas. Therefore if I had a 4GB quota (an 8th of the 32GB we could pack into an HP DL380) I could choose between 1 4GB VM or 4 1GB VMs or any other combination.

The leasing aspect was there to ensure that capacity was kept in active use. VMs would come with a 1 month lease, which had to be renewed by the requester to show that they still needed the VM. After 3 months that was it – the VM got deprovisioned. This ensured that we didn’t have stuff in a ‘development’ environment that was being treated as essential, and had the side benefit of ensuring that nothing remained unpatched for too long. It also forced people to automate their config management.

The quotas idea still lives on in some implementations, whilst leases never really caught on and got overtaken by the cost transparency of Infrastructure as a Service (IaaS) pricing models, whether that’s on demand, reserved instances, or spot pricing.

Conclusion

VM provisioning can be really fast. Not fraction of a second container fast[5], but fast enough where boot time is still a consideration.

VM provisioning can also be really slow, if the organisation wants it to be slow by throwing spend control and other barriers in the way of speed. That’s a choice (conscious or otherwise), and sometimes that choice needs to be properly surfaced and understood; particularly if one part of the organisation cares about speed whilst other parts have other cares.

Notes

[1] VDE became the Virtual Machine Provisioning System (VMPS), which became DynamicOps, which was acquired by VMware to become vRealize Automation (vRA). Other VM automation systems are available.
[2] See The #AWS EC2 Windows Secret Sauce for a detailed example.
[3] I once came across a bank (not one I worked at) that had built a 24h delay into its otherwise automated provisioning system so that the infrastructure services people could check that people had ‘asked for the right thing’. They felt that the delay provided a ‘cooling off’ period that prevented ill considered short term requests. To me this seemed like an act of open hostility by Ops towards their Dev colleagues.
[4] Workloads tend to get broken down into general purpose and compute intensive. The latter usually went onto dedicated High Performance Compute (HPC) environments, which came with their own provisioning and workload management (the grid). So VMs tended to be general purpose workloads that exhausted RAM before CPU.
[5] There are now systems that essentially merge container tech and VM tech that do break the sub second barrier.

 


Jessie FrazelleBryan Cantrill and Steve Tuck have announced the launch of Oxide Computer Company to deliver ‘hyperscaler infrastructure for the rest of us’. The company aims to tackle the ‘infrastructure privilege’ presently enjoyed by hyperscale operators by developing ‘software to manage a full rack from first principles’, including platform firmware.

Continue reading the full story at InfoQ.


I’ve never liked the hard plastic headphones that come with iPods and iPhones, so when AirPods were launched I was totally ‘meh’, especially as I though they looked ugly and uncomfortable.

When AirPods Pro launched a few weeks ago I was willing to reconsider, as I’ve got on OK in the past with silicone bud earphones.

Then I read the reviews, which were overwhelmingly gushing. So I’m here to gush a little more.

My AirPods Pro in their charging case with silicone cover

Magical

I’ve found that the AirPods Pro ‘just work’ in that magical way we expect from Apple’s commitment to design and user experience (but maybe don’t always get). The last time I was wowed so much was probably my first encounter with the iPod touch.

Device switching between my iPhone and iPad can be a little clunky, but in pretty much every other way they’re encouraging me to use my earphones more than I did with any previous ones because everything is so quick and easy.

Controls

Part of the magic is the single control present on both sides, with short clicks for pause, forward, back and a long click to switch between noise cancelling and transparent.

Noise isolation

This is the key selling point of the Pro version – active noise cancellation.

I used to buy headphones and earphones with active noise cancellation, and then I discovered Koss Sparkplugs, which are basically just memory foam earplugs with a sound pipe and drivers attached. So I’ve been passive for over a decade now.

The culmination of my passive approach to blocking out the noise is a pair of Snugs Flight (now called Snugs Travel), which were ridiculously expensive, but worth every penny because they deliver excellent noise isolation and are comfortable enough for a 12h+ flight.

Comparing the AirPods Pro to the Snugs in an airport lounge last week it was pretty much impossible to tell them apart on noise isolation or audio quality. So the AirPods Pro win there on price[1].

The AirPods Pro also win on having transparent mode, which is much easier than fishing a perfectly fitting earbud out when you want to hear the drinks/meal choices. They also give you the option to keep listening or pause the music[2].

Fit and comfort

The default (medium) buds seem to fit just fine – with a satisfying little pop when they seal. I tried the larger ones, as I’ve often used larger silicone buds in the past, but they’re just too big for my ears.

Comfort has been perfect for the hour or two I’ve worn them at a stretch; but then the batteries only last for about 4h so long term comfort isn’t really a practical concern.

I’ve had one instance of one of them seemingly leaping out of my ear as I turned my head, which makes me a little cautious about wearing them when boarding trains or in other situations where dropped too easily turns into lost forever or destroyed.

Looks

They don’t make you look like you’ve poked candy cigarettes into each ear :/

Conclusion

I love them, and they’re so good that they’ve changed how often I use earphones and how I use earphones. The best new Apple thing in a while.

Note

[1] I’ll still be travelling with the Snugs, because the AirPods Pro won’t last through a long flight, won’t plug in to in flight entertainment and you definitely can’t sleep in them (and I sometimes like to doze off whilst listening to an audio book).
[2] Though I do wonder about the whole being talked to whilst wearing earbuds thing as it will take a while for people to get used to the fact that they can be heard perfectly well by somebody who’s in transparent mode (for which there is no visual indication).


Key Takeaways

  • Ecstasy is a general purpose, type-safe, modular programming language built for the cloud
  • The team building Ecstacy plan to use it as the basis for a highly scalable Platform as a Service (PaaS)
  • Ecstasy is still in development and is not yet ready for production use
  • The Ecstacy team are looking for contributors that want to be involved with defining the future of our industry

Continue reading the full story at InfoQ.


Certification

11Oct19

TL;DR

Knowing how the cloud works is becoming essential knowledge in the IT industry, and getting certification is a reliable way of ensuring that knowledge is consistent and tested.

Background

Yesterday this excellent cartoon showed up in Forrest Brazeal’sFaaS and Furious‘ strip, it’s very timely as certification has been a hot topic at work lately as we’re building out a cloud professional services capability that will need hundreds of pro certified people.

My own initial journey

I first came across IT certifications as I was leaving the Navy and preparing for life ‘outside’. At the time Microsoft Certified Systems Engineer (MCSE) seemed to be the ticket to a well compensated new role, so along with a bunch of my colleagues I bought the books, built a home lab, and started taking the exams.

After lots of reading, and rebuilding, and re-configuring, and more reading of ‘brain dumps’ I was finally ready for my first exam. I started out with a single (Workstation) exam to get Microsoft Certified Professional (MCP), then a few months later two more (Server), then a few months later the final three (Networking and Web Server) to get MCSE.

At that stage I was a ‘paper’ MCSE with no experience beyond that home lab scraped together out of Y2K surplus PCs, but it was enough for me to be taken seriously and hired into a system admin role, and that quickly brought me real world experience.

Almost 20 years rolled by before I did another certification, not because I didn’t believe in their value (like the character pictured above), but more because I was on a continuous learning journey that was often ahead of mainstream adoption and the certification that comes with that.

More recently

As we were bringing together DXC our CTO Dan Hushon asked his team to ‘get a cloud or DevOps certification’ before the new company launch day.

I ended up booking the last remaining slot in the London test centre a short walk from the office for the AWS Certified Solution Architect – Associate (CSA-A) exam. I’d been using AWS from the beginning[1], but not all of it, because there’s a tremendous volume of services now, so I used the A Cloud Guru course to fill the gaps in my knowledge.

Even more recently

I’ve been involved in DXC’s partnership with Google Cloud Platform (GCP) so I took advantage of the recent certification challenge to check out the training material and then took exams for Associate Cloud Engineer (ACE) and Professional Cloud Architect (PCA).

For detailed accounts of my prep for those exams check out my A Cloud Guru forum posts for ACE and PCA. Generally I’d say I’m not a big fan of watching videos as a means of learning, much preferring interactive training, which I wrote about before in The Future of tech Skills Training.

What’s the point?

I think for all the groups highlighted in the cartoon above it’s to get taken seriously, and to have a shot at getting an initial job in IT.

For those already in IT the point is completely different. The landscape is increasingly defined by the 3 major cloud providers (AWS, Azure and GCP) and an associate level certification shows that you understand how at least one of them works, and that such knowledge isn’t superficial. A pro level cert shows (significantly) greater depth of knowledge, and specially certs, or certs from more than one cloud show a breadth of knowledge.

Note

[1] I signed up for the original Amazon Web Services to use as a test point for some work I was doing. It was a SOAP or XML over HTTP based ‘web service’ that allowed books to be looked up by ISBN and other stuff by ASIN. So when services like EC2 and S3 came along I already had an account.


TL;DR

Yesterday the IET shut down their email alias service, which is the only thing I cared about as a member. So come 2020 I expect that I’ll no longer be a member (MIET) or keep the designation of Chartered Engineer (CEng) that goes with that.

Background

I joined the Institution of Electrical Engineers (IEE) as a student associate member during the early days of my electronics degree in 1990. In the summer of 1996 they launched an email forwarding service for members and I became [email protected], which was my primary online identity until 15 months ago when they announced that the service would be shut down.

Email was the only service I cared about

For almost 30 years I kept paying my dues.

In early ’99 I completed the process to become a ‘corporate’ member (MIEE) and a Chartered Engineer (CEng), which was highly encouraged in the Royal Navy (and they did provide an excellent IEE approved training scheme[1]). I had just turned 28[2]. My identity as an engineer was further reinforced, the Internet was exploding into every aspect of daily life, and I was @iee.org.

In ’06 the IEE merged with the Institution of Incorporated Engineers (IIE) to become the Institution of Engineering and Technology (IET). It was not a move I supported or welcomed, and they didn’t even have the domain iet.org – instead having theiet.org. But at least they kept on forwarding @iee.org email.

A few years later new wiring regulations published by The IET meant that their Chartered Engineer members (and fellows) weren’t even allowed to run an extension socket in their own home, causing outcry amongst many old timers. But at least they kept on forwarding @iee.org email.

In ’12 a colleague offered to sponsor my application for Fellow (FIET), which in the end I didn’t do. But at least they kept on forwarding @iee.org email.

Last year my physical membership card broke. They refused to send me a new one without a rigmarole of (insecure) privacy theatre. It became a symbol of our broken relationship:

Image

I knew by then that there was little point in getting a new one.

Letters after my name

When I was a junior naval officer it was usual for more senior officers to have brass name tallies on their door like Lt Cdr Mike Watt RN BEng CEng MIEE.

That isn’t a thing any more. Not in the Navy, or in any other walk of life that I typically encounter. My company (in keeping with modern convention) doesn’t even let me put letters after my name on my business card.

Professional subscriptions

My company also instituted a policy that ‘memberships and subscriptions for individuals is not a reimbursable expense’. If my employer doesn’t care that I’m CEng MIET then why should I?

Join the BCS instead?

Probably not.

I have a few months left to make my mind up on this and possibly transfer my CEng, so I’m still ‘thinking grey‘ about it.

But on the balance of probability I probably won’t bother.

I asked a friend who’s a Fellow of the British Computer Society (FBCS) who didn’t do a great job of persuading me.

And then it was another FBCS who recently told me ‘I’m not technical‘ – hardly inspiring.

Conclusion

The IET and I drifted apart many years ago, but I tolerated the self serving executive and increasing irrelevance to the modern world because their email redirection embodied my identity. But that’s gone now, and I have no reason left to stay (never mind pay £hundreds a year).

Notes

[1] Most of the training was alongside colleagues specialising in marine engineering and aeronautical engineering, so things like workshops had to cater to the IEE, the IMechE and RAeS. Alongside making printed circuit boards and soldering I learned welding, fitting and turning, milling, pattern-making and moulding. It’s a set of practical skills that have served me well through my adult life.
[2] In theory it was possible to make CEng at 27, but delays in my training pipeline meant that I’d just tipped past my 28th birthday when I crossed the line.