Rise of the Stack Developer History

05/06/19 • 19 min

System Admin - 2002
Stack Developer - 2019

System Administration, Configuration Management, Build Engineer, and DevOps many of the same responsibilities but over the years the names have changed. Listen as Darren Pulsipher gives a brief history of his journey through the software and product development over the last four decades and how so much has changed and much has remained the same.

Darren’s History

Started as a Software Programmer
Had Linux and Unix Experience
- Tell Story of Mimi Larson getting me an AT&T Unix box and a manual in 1985
- Worked as a System Administrator in College (AIX, HPUX, VMS, SunOS, Solaris, Xwindows)
Always designated as the software developer that would do the build at night.
Learned about SCCS and the newer RCS at my first job.
Quickly become the configuration management grunt.
Changes in Version Control Systems and Build systems began to collide with each other.
Client-Server tools arose and started being spread across multiple machines. The rise of the Concurrent Version System. (CVS and tools like ClearCase)
For you young bucks you have probably heard of ClearCase, but it was my money tree for about 10 years. The black art of ClearCase administration was my sweet spot.
ClearCase really brought build and configuration management together with build avoidance and management of derived objects and binaries for the first time.
Then can truly distributed, de-centralized, simplified tools like git, mercurial. Convention over configurability made these tools easier to use and the Configuration Management engineering job shifted again. Focused on more build systems and Continuous Integration and Delivery.
The DevOps Engineer was born.
As development cycles decreased and build cycle times when from days to hours to minutes. Development teams took a more dynamic and Release-break-fix mentality.
Now with microservices, containers and serverless, a new role is starting to emerge.
The Stack Developer.
- develop new stacks of services across multiple environments (Local, Dev, Build, Test, and Production)
- These stacks can be made of multiple services and microservices.
- Talk about a stack being different in the different environments.
- Simple Mean stack first.
  - Local. One mongo instance, One nodejs worker node
  - Dev. One Mongo Instance, Multiple NodeJS worker nodes.
  - Build. Build environment might be completely different.
  - Test. Multiple instances of the same product with additional services for performance testing, logging, debug turned on, etc..
  - Production. Backup, Fault tolerance, etc...
- Creating these re-usable stack gives developers the ability to develop applications and not worry about system administration tasks.

System Admin - 2002
Stack Developer - 2019

Darren’s History

Started as a Software Programmer
Had Linux and Unix Experience
- Tell Story of Mimi Larson getting me an AT&T Unix box and a manual in 1985
- Worked as a System Administrator in College (AIX, HPUX, VMS, SunOS, Solaris, Xwindows)
Always designated as the software developer that would do the build at night.
Learned about SCCS and the newer RCS at my first job.
Quickly become the configuration management grunt.
Changes in Version Control Systems and Build systems began to collide with each other.
Client-Server tools arose and started being spread across multiple machines. The rise of the Concurrent Version System. (CVS and tools like ClearCase)
For you young bucks you have probably heard of ClearCase, but it was my money tree for about 10 years. The black art of ClearCase administration was my sweet spot.
ClearCase really brought build and configuration management together with build avoidance and management of derived objects and binaries for the first time.
Then can truly distributed, de-centralized, simplified tools like git, mercurial. Convention over configurability made these tools easier to use and the Configuration Management engineering job shifted again. Focused on more build systems and Continuous Integration and Delivery.
The DevOps Engineer was born.
As development cycles decreased and build cycle times when from days to hours to minutes. Development teams took a more dynamic and Release-break-fix mentality.
Now with microservices, containers and serverless, a new role is starting to emerge.
The Stack Developer.
- develop new stacks of services across multiple environments (Local, Dev, Build, Test, and Production)
- These stacks can be made of multiple services and microservices.
- Talk about a stack being different in the different environments.
- Simple Mean stack first.
  - Local. One mongo instance, One nodejs worker node
  - Dev. One Mongo Instance, Multiple NodeJS worker nodes.
  - Build. Build environment might be completely different.
  - Test. Multiple instances of the same product with additional services for performance testing, logging, debug turned on, etc..
  - Production. Backup, Fault tolerance, etc...
- Creating these re-usable stack gives developers the ability to develop applications and not worry about system administration tasks.

Next Episode

Podcast 1:2 - Legacy integration with Robotic Process Automation

One of the growing areas to help with Legacy Integration and automation of integration is the use of automation tools and frameworks. Over the last 3 years, a significant emphasis on the automation of workflows with legacy and new cloud-aware applications for information workers has emerged. These tools sets are called Robotic Process Automation (RPA) tools.

Robotic Process Automation (RPA)

What RPAs are NOT

A method to control and manage Robots
Process automation for factory machines
A way of replacing workers

What RPAs are

A way of automating Information Workers redundant tasks
A set of tools that records how Users interact with applications and plays it back
A way to decrease errors in highly repetitive, user interface intensive Tasks

Current Market Place – 2019

UiPath - $1 Billion investment on $300 Million in Annual Revenue
Automation Anywhere - $500 Million investment on $100 Million in Annual Revenue
BluePrism - $50 Million investment on $30 Million in Annual Revenue

Place where RPA works well

Financial Institutions
Medical Field
Insurance
Any place where lots of Information Workers do highly repetitive manual tasks
Understand your Information Worker

RPA Modes of Operation

Attended

· Handles tasks for individual employees

· Employees trigger and direct a bot to carry out an activity

· Employees trigger bots to automate tasks as needed at any time

· Increases productivity and customer satisfaction at call centers and other service desk environments

Unattended

· Automates back-office processes at scale

· Provisioned based on rules-based processes

· Bots complete business processes without human intervention per a predetermined schedule

· Frees employees from rote work, lowering costs, improving compliance, and accelerating processes

How to integrate RPA in your Enterprise

Information Worker – This is the primary user of the RPA tools. Their manual processes are targets for automation.
Application Developer – RPA bots change when applications are updated or created. Changes to User Interface require “re-recording” the RPA bots.
IT Operations – Manage the RPA tools and deploy unattended RPA bots.

Managing Change

Decrease number of updates to applications and user interfaces
Decrease number of steps if possible.
Decrease the number of tools integrated together.

Managing Security

Find a tool that allows for the injection of security credentials into the RPA bot
Look at auth keys instead of username and passwords

Managing RPA tools and bots with SecDevOps Workflows

RPA Bundling

SecDevOps Pipelining

Pitfalls of RPA bots

Security can be a gaping hole if you don’t pay attention to it. One of the biggest mistakes is running applications in an RPA bot in privileged mode or with a “global” account credentials.
RPAs bots tightly couple to User Interfaces of multiple applications, any small change to an application means you need to re-record the RPA bot.
RPA bots cannot hand change very well they are very brittle to change in applications and even configuration of applications.
Reuse is minimal due to the tight coupling with the application user interfaces. Some tools use tags instead of the absolute position of cursor and clicks.
Some User Interfaces do not allow themselves to RPAs because they are dynamic. Which means they are hard to record.

Tips and Tricks

· Treat RPAs as Complex Services running in your Multi-Hybrid Cloud

· Run you RPA bots through SecDevOps Workflows like other applications.

· Inject Security and Auth at runtime into the RPA tool.

· Find ways to reuse RPA bots in different parts of your organization.

· Have a plan to replace your RPA bot with a simplified integration

·&nbsp...