Pivotal Blog

Would the cost/savings also depend on the 'predictability' of the infrastructure needs? To me, it seems like there is a dependency.

For example if I can project steady growth or decline of my needs, it seems that I benefit less from the infrastructure-on-demand like AWS/Azure/GC

Also, depending on the size of the organization it seems that there at least several options on data centers:

- have my own data center
- collocate my hardware in other's data center
- rent hardware
- use infrastructure-on-demand + software-as-a-service

AWS/Azure/GC are in 4th category, but cost savings in terms of electricity/building capacity/peering points are available in the first 3 as well.

Many organizations deploy Pivotal's
https://pivotal.io/industries/financial-services

or Redhat/OpenStack

So they are not actually 'building' the infrastructure management layer from scratch.

Also for investment banks (due to exchange connectivity) , telecoms (due to peering points, physical tower locations) always going to have their 'Front-office' applications in data centers that offer lowest latency for those apps.

Midoffice applications (or BOSS as they are labeled in telecom) can live in data centers reasonably distant (in terms of ping time) from the front office.
So the infrastructure for those has a different cost profile.

Most of this applications touch trades or trade events that carry millions of dollars worth of contract value
(not Facebook's likes or favorites... )

There is…

I had been quite skeptical of Clean Architecture when I first came across it. I don't find Uncle Bob's post on it particularly insightful; for me it's not vocational enough.

Then a few years ago I had to maintain a software stack written by contractors from Pivotal (https://pivotal.io/) in a Clean Architecture style - it was truly a revelation for me; akin to that "aha" moment of fully grokking homoiconicity in LISPs.

Now, up until this point, all code I'd encountered at Twitch heavily reflected the domain of the problem it was solving and the technology in which it was written. That is, if you were looking at a certain piece of architecture you had to really fully understand not only exactly the intent of that code base but also the details of the framework in which it was written. As codebases increased in number and size, it became much harder to scale as an engineer. Jumping from a Rails monolith, to a highly concurrent Golang HTTP CRUD-API, to a highly asynchronous Twisted-Python request routing system (broadly the main three backend techs) had a very large cognitive load. The eng org cleaved along these lines and maintaining velocity in that world was very hard; attempts to introduce new tech or join chunks of the org took on a "religious" tone.

So initially coming across this clean architecture stack felt very similar to that. It had a lot of "weird new things" in it, but once I understood that much of it was routing (tagging inbound requests in a manner that a…

In my view what we're really talking about here is PaaS. Every shop is left to implement a private PaaS on their own for the most part. There are software companies out there who specialize in helping teams deploy this kind of architecture for example:

https://pivotal.io/platform

http://deis.io/

both are open source technologies based on Docker that are gathering momentum and you can hire consultants to help you deploy either one.

I personally don't use Docker. The startup I'm building has chosen to standardize on the JVM for all application code so we leverage the JAR file as a kind of container. The Java ecosystem already solved the problem of zero-downtime deployments a long time ago so for us deploying can be as simple as shipping new jars file across the network.

Instead of using Docker to drive development we simply spin up development database/redis/etc instances in the cloud which automatically join a development VPN network. All of the non-VPN interfaces are automatically firewalled off. One nice advantage of this setup is that developers who have slow laptops are still able to work. I'm a big fan of this approach.

Check out Wildfly's "High Availablity" features if you're interested in one way that the Java Ecosystem can make headaches like zero-downtime deployment, HTTP health checks, monitoring, caching, and even load balancing disappear.. It'll deploy non-java code too as long as it's on the JVM. If you're a Scala only shop there are some great…

> They have their own sauce. I personally called it the Pivotal Process

What Pivotal does is fairly vanilla Extreme Programming. Indeed, the vanillaness of it is something of a selling point. In the London office, we would start projects by giving client PMs and programmers a copy of Extreme Programming Explained and telling them that was what we were going to do. It's easier to coax them into following a process if it's a documented industry-standard one rather than some special sauce.

Pivotal does have a few extra bells and whistles that fill in spaces around the XP core - "discovery and framing" [1] and "inception" [2] being two that spring to mind. And as you say, there is less emphasis on iterations as a unit of work - the planning meeting is weekly, but it feeds a continuous flow of development and delivery. But the daily pattern of work should be familiar to anyone who knows XP.

[1] https://content.pivotal.io/blog/what-we-did-on-our-summer-internship-at-pivotal-discovery-and-framing

[2] https://www.infoq.com/articles/project-inception-meeting/

What you are describing is a pretty poor pairing interview process. I did a bunch of really frustrating whiteboard type interviews and sudo pairing interviews like you describe before interviewing for my current position [1].

The screen is a one hour onsite pairing session followed by a final round that is a day of pairing using a proper workstation: One computer, two monitors and two sets of mice/keyboards. You pair with one person in the morning and another in the afternoon. It's very relaxed (you take turns "driving") and it gives you and the interviewers a lot more information about each other and your potential place of work. It also gives you enough time to adjust to the process if you are nervous. I don't think I'd do it any other way going forward.

[1] http://pivotal.io/careers

Didn't understand much from the linked page, but I found this website (from Pivotal, the commercial entity behind Geode) quite informative. Perhaps it's useful to others.

https://pivotal.io/big-data/pivotal-gemfire

===

I found this interesting deployment:

China National Railways use Geode to run railway ticketing for the entire
country with a 10 node cluster, managing 2 TB of "hot data" in memory,
and 10 backup nodes for high availability and elastic scale.

Holiday travel periods [Chinese New Year's] create peaks of 15,000 tickets
sold per minute, 1.4 billion page views per day and 40,000 visits per second.

http://pivotal.io/big-data/case-study/scaling-online-sales-for-the-largest-railway-in-the-world-china-railway-corporation