This document discusses opportunities to improve developer velocity through increased abstraction levels. It begins by outlining challenges in keeping up with changing technologies and biases. Containerization, virtualization, and cloud platforms are presented as offering abstraction that improves velocity. Examples show how programming languages, frameworks, and infrastructure have progressively improved developer productivity over time. The key message is that businesses should focus on the highest possible abstraction level to maximize value, defaulting to programming languages like Java and platform as a service (PaaS) for most applications. Microservices are discussed but not recommended as a default approach due to increased complexity risks outweighing potential benefits for many use cases.

1. IMPROVING VELOCITY
THROUGH ABSTRACTION
A PRIMER ON CONTAINERIZATION,
VIRTUALIZATION, AND THE CLOUD

2. ALL ABOARD THE HYPE TRAIN
NON-STOP TO THE SCRAPYARD

3. HARD TO MAKE INFORMED TECH DECISIONS
▸ Hype - NetFlix is doing it!
▸ Fast Pace of Technology - React or Angular?
▸ Biases - Shiny Object Syndrome
▸ Self-Interest - Lack of Skin-in-the-Game
▸ LOSE TRACK OF WHAT’S IMPORTANT ….

4. SHOW ME THE MONEY VALUE

5. BUSINESS VALUE
What your customers want!
VELOCITY
Business Value over Time

6. Do modern day opportunities
still exist to improve Velocity ?
…and at Force-Multiplier levels!!
YES!!!

7. PACMAN

8. 1980 2005
Assembly Java
1 Developer* 1 Developer
1 Year Dev 2 Day Dev
2 Month Dev
20x Improvement!!

9. 787 DREAMLINER

10. 2009
32 Billion Dollar Project
Cutting-Edge Technology
0.15x Improvement!!

11. 95%
5% Business Value
?
?
?
?
?
DEVELOPER PRODUCTIVITY

12. ASSEMBLY CODE
ld hl,#36a5
rst #18
ld e,(hl)
inc hl
ld d,(hl)
ld ix,#4400
add ix,de
push ix
ld de,#fc00
add ix,de
ld de,#ffff
bit 7,(hl)
jr nz,#2c7c
ld de,#ffe0
inc hl
ld a,b
ld bc,#0000
add a,a
jr c,#2cac
ld a,(hl)
cp #2f
jr z,#2c92
ld (ix+#00),a
inc hl
add ix,de
inc b
jr #2c84
inc hl
pop ix
ld a,(hl)
and a
jp m,#2ca4
ld a,(hl)
ld (ix+#00),a
inc hl
add ix,de
djnz #2c9a
ret
; (hl+2*b) -> hl
; Start of Color RAM
; Calculate starting pos in CRAM
; 4400 + (hl) -> stack
; Calculate starting pos in VRAM
; Offset for normal text
; (3)
; Offset for top + bottom 2 lines
; b -> a
; 0 -> b,c
; 2*a -> a
; Special Draw routine for entries 80+
; Read next char
; #2f = end of text
; Done with VRAM
; Write char to screen
; Next char
; Calc next VRAM pos
; Inc char count
; loop
; Get CRAM start pos
; Get color
; Jump if > #80
; Get color
; Drop in CRAM
; Next color
; Calc next CRAM pos
; Loop until b=0

13. JAVA CODE
Font smallfont = new Font("Helvetica", Font.BOLD, 14);
graphics.setFont(smallfont);
graphics.setColor(Color.BLUE);
graphics.drawString("'S' to start game", 120, 100);

14. “NO MATTER THE PROGRAMMING
LANGUAGE CHOSEN,
A PROFESSIONAL DEVELOPER WILL
WRITE IN AVERAGE 10 LINES OF CODE
(LOC) DAY. “
FRED BROOKS (MYTHICAL MAN MONTH)

15. JAVA
ASSEMBLY
C/C++
VELOCITYKOTLIN ABSTRACTION
Performance is no longer a driving factor !!

16. “THE BEST CODE IS NO CODE AT ALL“
JEFF ATWOOD
CODING HORROR / STACKOVERLOW

17. DEVELOPER PRODUCTIVITY
HIGHER
Business Value
Registers
Memory Management
Performance Focus
Verboseness
Null Checking
DIY
Chipset specific code
Gotos

18. Here is my business logic;
run it on a chip for me;
I don’t care how.

19. So, how do we further
improve Velocity ?

20. OPPORTUNITIES
▸ Diminishing Returns with Programming
Languages
▸ Development Eco-system / Frameworks /
Practices
▸Infrastructure

21. Here is my app;
run it for me;
I don’t care how.
DEVELOPER FOCUS

22. Here are my servers;
Set them up and maintain them
for me;
I don’t care how.
OPS FOCUS

23. 95%
5% Value
?
?
?
?
?
DEVELOPER PRODUCTIVITY
+ OPS EFFICIENCY

24. PAAS
BARE-METAL
IAAS
VELOCITYABSTRACTION
CAAS / IAAS+

25. BARE METAL / ON-PREM
OS+APP
HARDWARE
OS+APP
HARDWARE
OS+APP
HARDWARE
Long lead time !

26. VM
VIRTUAL MACHINES (VM’S)
OS+APP
HOST OS
HARDWARE
VM
OS+APP
VM
OS+APP

27. CLOUD
▸ API to some shared pool of resources
▸ Typically: Rapid, On-Demand, Elastic, and
Self-Serve
▸ Public, Private, or Hybrid

28. INFRASTRUCTURE AS A SERVICE (IAAS)
▸ OpenStack, vSphere, AWS, etc
▸ API for virtualized infrastructure
▸ Compute / Network / Storage
▸ Including “Infrastructure Orchestration”
▸ Auto-Healing, Bin-Packing, Scaling, etc

29. ON-PREM IAAS
OS
HARDWARE
MIDDLEWARE
APPLICATION
VIRTUALIZATION
OS
HARDWARE
MIDDLEWARE
APPLICATION
VIRTUALIZATION
YOU MANAGE
OTHERS MANAGE
Note .. you’re still on the hook for the OS!
Clear separation of concerns …

30. VM VM
CONTAINERS
OS
HOST OS
OS
APP + BIN
OS
APP + BIN
HARDWARE
CONTAINER ENGINE
CONTAINERCONTAINER
REALLY BIG!
WHO MANAGES IT ?

31. CONTAINERS
▸ Lightweight, stand-alone, portable, executable package of
software to run specific services
▸ Runs as an isolated process, but on a SHARED Operating
System
▸ Allows for more efficient resource consumption
▸ History back to 1979 (chroot) and 2000 (FreeBSD Jails)
▸ Numerous different Containers exist …
▸ Often sharing the same underlying tech - runc / containerd

32. DOCKER
▸ Docker the Company
▸ Docker the Containerization Technology
▸ Packaging, Deploying, and Running Docker Images
▸ Popularized container technologies ~2013
▸ First big win was local containers on developer machines
▸ CTO / Founder Solomon Hykes departure - March/28/18
▸ Not the ONLY nor the FIRST container technology ..
▸ Ex-passenger on the Hype Train ?

33. ON-PREM IAAS
OS
HARDWARE
MIDDLEWARE
APPLICATION
VIRTUALIZATION
OS
HARDWARE
MIDDLEWARE
APPLICATION
VIRTUALIZATION
YOU MANAGE
OTHERS MANAGE
CAAS
CONTAINER AS A SERVICE
OS
HARDWARE
CONTAINER
MIDDLEWARE
VIRTUALIZATION
APPLICATION
No longer responsible for OS! (better for security)

34. CONTAINER AS A SERVICE (CAAS/IAAS+)
▸ Kubernetes, Docker Swarm, Apache Mesos, etc
▸ API at Container level
▸ OS abstraction
▸ Including “Container Orchestration”
▸ Auto-Healing, Bin-Packing, Scaling, etc

35. KUBERNETES (K8S)
▸ Open-Source Docker-based Container Orchestration / CaaS /
IaaS+ by Google
▸ Used to deployed BILLIONS of containers per month on
Google’s infrastructure
▸ Adds concept of Pods - groupings of containers
▸ Popularized Container Orchestration ~2015
▸ Not the ONLY nor the FIRST container orchestration tool..
▸ Full steam ahead for the Hype Train !!

36. KUBERNETES PHILOSOPHY
Here’s my code;
I’ll tell you EXACTLY how you
should run it for me;
and don’t you dare make any
assumptions on the deployment
WITHOUT my written consent!

37. DEPLOYING TO KUBERNETES
▸ Define Docker File
▸ Define Deployment, Pod, Networking, and
Services
▸ Publish to Registry
▸ Deploy
▸ kubectl run my-app

38. WORK REQUIRED
▸ Configuration Management
▸ Binary Management
▸ Memory Management
▸ JVM* and older Linux tools (free / top) will look at the OS host
OVERALL memory / CPU counts instead of container ones !!
▸ “Why you’re going to FAIL running Java on Docker” - Redhat
Workshop

39. Here is my app;
run it for me;
I don’t care how.

40. CONTAINER / VM
PLATFORMS?
BINARIES /
DEPENDENCIES
APPLICATION
BUILDPACK

41. ON-PREM IAAS
OS
HARDWARE
MIDDLEWARE
APPLICATION
VIRTUALIZATION
OS
HARDWARE
MIDDLEWARE
APPLICATION
VIRTUALIZATION
YOU
MANAGE
OTHERS
MANAGE
CAAS
OS
HARDWARE
CONTAINER / POD
MIDDLEWARE
VIRTUALIZATION
APPLICATION
PAAS
OS
HARDWARE
CONTAINER
MIDDLEWARE
VIRTUALIZATION
APPLICATION
Dev Focus is now on Application Development

42. PLATFORM AS A SERVICE (PAAS)
▸ AWS Beanstalk / PCF / Heroku / ETC
▸ Popularized by Heroku ~2009
▸ API at Application Level
▸ VM or Container hosted!
▸ Including “Application Orchestration”
▸ Auto-Healing, Bin-Packing, Scaling, etc

43. PIVOTAL CLOUD FOUNDRY (PCF)
▸ Container-based Open-Source PaaS by Pivotal
▸ MultiCloud (Public / Private or Hybrid)
▸ Modern Cloud-Native / 12 Factor Apps
▸ Deployments: Java, .NET Native, NodeJS, Docker, Go, etc
▸ Also includes:
▸ PKS - Pivotal Container Service (Kubernetes)
▸ PFS - Pivotal Function Service

44. DEPLOYING TO PCF
▸ Deploy
▸ cf push my-app

45. HIGHER
Business Value
Manual Scaling
Container Management
Orchestration
Verboseness
Manual Updates / Reboots
DIY
DEVELOPER PRODUCTIVITY
+ OPS EFFICIENCY

46. ABSTRACTION
PAAS
BARE-METAL
IAAS
CAAS / IAAS+

47. To maximize BUSINESS VALUE..
.. work at the highest
abstraction level possible.
THE POINT

48. For the MAJORITY (>99%) of GreenField
business apps, default to:
Java for programming language*.
PaaS for infrastructure*.
*or higher

49. Economics have shifted where general
focus should be:
Developer productivity over performance
and flexibility.

50. QUESTIONS TO ASK ..
(WHEN OPTIMIZING, NEEDING A LOWER ABSTRACTION LEVEL)
▸ What is your bottleneck ?
▸ Hardware is cheap! Developers are expensive!
▸ You’re not Google / NetFlix !
▸ Profile!
▸ Are you re-inventing the wheel ?
▸ Compare to off-the-shelve solutions
▸ Have you weighted the costs ?
▸ Not a free lunch !!
▸ Understand that you’re trading off productivity

51. MICROSERVICES
▸ Independently deployable, small, modular
services instead of larger Monolith style apps
▸ Not really a new concept !
▸ Service Oriented Architecture (SOA) has been
around for much longer!
▸ Passenger on the Hype Train since ~2014!

52. Do MicroServices increase Velocity ?
IT DEPENDS!!!
and they can often
NEGATIVELY affect it!!

53. NOT A SILVER BULLET !
▸ Net Complexity Booster!! / Not an Abstraction !
▸ Debugging costs
▸ Refactoring costs
▸ Multiple SCM Management
▸ Deployment CI/CD costs
▸ API Versioning
▸ Retry Logic
▸ Performance Hit (Networks are slower!!)
▸ Transactions

54. “DON'T LEAP INTO MICROSERVICES
JUST BECAUSE IT SOUNDS COOL.
SEGREGATE THE SYSTEM INTO JARS
USING A PLUGIN ARCHITECTURE
FIRST.
IF THAT'S NOT SUFFICIENT, THEN
CONSIDER INTRODUCING SERVICE
BOUNDARIES AT STRATEGIC POINTS.”
UNCLE BOB (ROBERT C MARTIN)

55. “I'M WARY OF DISTRIBUTION AND MY
DEFAULT INCLINATION IS TO PREFER A
MONOLITHIC DESIGN.”
MARTIN FOWLER

56. “IF YOU CAN’T BUILD A WELL-
STRUCTURED MONOLITH,
WHAT MAKES YOU THINK YOU CAN BUILD
A WELL-STRUCTURED SET OF
MICROSERVICES?”
SIMON BROWN
CODING THE ARCHITECTURE

57. RECOMMENDATIONS
▸ Monoliths are NOT a bad thing !!
▸ MicroServices are NOT a replacement / but an alternative!
▸ Ensure proper DevOps first
▸ For Performance:
▸ Tech Giant Fallacy - You’re not NetFlix!
▸ Profile !! What is your Bottleneck ?
▸ Consider “Cookie Cutter” scaling !
▸CONSIDER AND UNDERSTAND THE COSTS!!
▸WEIGHT THE PROS AND CONS!!

58. THE SWEET SPOT (DEFAULT)
Monolith
1 ∞
Number of MicroServices
Per FunctionPer Agile Team
Super
?

59. THE QUESTION THAT YOU
SHOULD ALWAYS BE ASKING ..
IS THIS ADDING BUSINESS VALUE?

60. “IN DEFERENCE TO THE GODS OF
YAGNI,
WHEN IN DOUBT ERR ON THE SIDE OF
SIMPLICITY. ”
MARTIN FOWLER

61. Victor Szoltysek
Platform Architect @ Pivotal
vszoltysek@pivotal.io