Get Mapped: Value Stream Mapping

twain

Value stream mapping (VSM) does exactly that: it is a DevOps framework (“borrowed” from manufacturing) that provides a structured way for cross-functional teams to collectively see where we are today (long release cycles, silos, damage control afterwards, etc.) and where we want to be in the future (short release cycles, infrastructure as code, iterative development, continuous delivery, etc.).

A VSM is a way of getting people to collaborate and see what is really happening. These exercises are often amazing “aha!” moment workshops that make three objectives (flow, feedback, and continuous integration) turn into a sustainable engine of improvement.

Who should participate in a VSM?

  •    Service Stakeholders and Customers
  •    Executors of a Process Tasks
  •    Management

…but not all at the same time.

The VSM process assembles everyone involved with a workflow in the same room to clarify their roles in the product delivery process and identify bottlenecks, friction points and handoff concerns. Realistically, if we include everyone at the same time, the likelihood of honesty decreases. Let’s be for real – if upper management were in the room with you, would you be 100% honest as to where the bodies are buried or exactly what processes each step entails? VSM reveals steps in development, test, release and operations support that waste time or are needlessly complicated and this requires complete transparency.

Lead Time versus Time on Task

If you can’t measure it, you can’t improve it. Why do companies go for Continuous Delivery (CD)? Why do people care about DevOps? The main reason I hear is cycle time. This is the time it takes me to get from an idea to a product or feature that your customers can use. Measurement is one of the core foundations of DevOps, and the VSM is the measurement phase. If you do it right, it’s the sharing phase as well – share the measurements and proposed changes with the entire group. Doing that well allows you to start to change culture simultaneously.

Lead time vs time on task

With a solid foundation in place, it becomes easier to capture more sophisticated metrics around feature usage, customer journeys, and ensuring that service level agreements (SLAs) are met. The information received becomes handy when it’s time for road mapping and spec’ing out the next big project.

“Lead time” is a term borrowed from manufacturing, but in the software domain, lead time can be described more abstractly as the time elapsed between the identification of a requirement and its fulfillment.

The goal of VSM development is to measure how time is spent on each task and identify processes required for each task. It becomes easier to see what processes are inefficient and creating a bottleneck. In turn, this will reduce the lead time to deliver the finished release.

Current State

The following VSM demonstrates a current state analysis of the current software release process. The main thing to note in this example is how linear it is – there are only two feedback loops: at the very beginning and towards the end at new feature testing.

current state

The apparent lack of feedback loops presents a potential problem area – there are 8 steps between the two feedback loops. Imagine getting all the way to the end before realizing there’s an issue and providing feedback. How far will the software release be set back if the problem is not detected and communicated until the new release testing phase?

Future State

Once you have the current state VSM mapped, the next step is to figure out a way to make the mapping more efficient. This is typically driven by the following:

  • How can we significantly increase the percent complete and accurate work for each step in our current state VSM?
  • How can we dramatically reduce, or even eliminate the non-productive time in the lead time of each current state step?
  • How can we improve the performance of the value added time in each current state step?

future

Realistically, no VSM is perfect. However, the future state that we see above demonstrates a set of processes that create a mostly ongoing feedback loop. This allows for continuous communication about the processes and release as it moves forward towards a qualified build.

Demonstrating Business Value

In the manufacturing plants, they would have one pipeline, one production line at a time. As we know, the modern software development world is not like that.

A VSM is about more than just dissecting the software delivery lifecycle to find bottlenecks and pain points, although it is certainly helpful in that area. Analyzing value streams gives management confidence that the business is focusing on the right projects and initiatives. By taking a clearer look at the KPIs and metrics across the tooling and scaling the entire organization, these leaders can make informed decisions the way most business leaders prefer to—with data to back them up.

Continued Enhancements in vSphere 6.7

vSphere 6.7 is finally upon us. It should not be a surprise that vSphere is focused on more efficient manageability, especially at scale, and increased security. These design qualities have become paramount as VMware continues to partner with public cloud vendors (AWS, Microsoft Azure) to deliver “hybrid” offerings and as more edge sites are added into the data center’s purview.

Nearly everything in the vSphere suite has gotten a minor facelift for this new release. The one upgrade consideration that caught my eye:

It is not supported to upgrade from vSphere 5.5 to vSphere 6.7. This introduces a multi-step upgrade path.

Additionally, upgrading from 6.5u2 is not currently support but will be added in future releases of 6.7.x so watch for that if it affects you. Refer to my previous blog post about architecting upgrades.

vCenter Server Appliance (vCSA)

I have long been a fan of the vCSA since its initial announcement in 5.0. I thought that combining the app and OS, putting it in VMware’s control could increase security and lead to quicker updates and innovations. Unfortunately, while consulting I found that many customers misunderstood the architecture introduced in 6.x (PSC and vCSA), which led to more confusion than upgrades.

Therefore, the road led has led to 6.7 where VMware has simplified the vCenter Server topology by now supporting vCenter Server with an embedded platform services controller running in enhanced linked mode (ELM). ELM allows customers to link multiple vCenter Servers together for increased visibility aka ‘single pane of glass’ (drink!). This change allows this architectural design decision without the complexity of external PSCs or load balancers.

vCSA

For the rest of the vCenter goodness, check out Emad Younis’ post about the rest of the vCSA enhancements.

Increased Security

In a world where cybersecurity is allocated billions of dollars of the Federal budget and ransomware attacks are commonplace, it only makes sense for companies like VMware to invest in increasing security capabilities. The heart of the vSphere platform is ESXi, therefore it makes sense to start there.

Support for Trusted Platform Module (TPM) 2.0 and the introduction of Virtual TPM 2.0 has been added with vSphere 6.7. If you are unfamiliar with TPM, it enables ESXi to verify drivers/boot components, effectively validating its image during the boot process. It measures the VMkernel with its Platform Configuration Modules to make sure the image is still authentic and hasn’t been changed.

Additionally, VM Encryption has been enhanced to make assignment of this policy a simple right-click. Moreover, encrypted vMotion for cross-vCenter migrations (including versions) addresses the age old security concern about data being migrated in clear-text.

Lastly, VMware has announced support for the entire Microsoft Virtualization Based Security portfolio. I am very interested to see how this plays out, especially as it pertains to NSX.

vSAN 6.7

It is no secret that I find storage enhancement announcements to be jejune. However, I concede that it is important to consistently improve performance, consistency, and usability.

These days, I am more interested in using APIs to interact with software. But I do believe that a simple and performant user interface is necessary in 2018. I am happy to see that vSAN has a new HTML5 UI built on the same “Clarity” framework used by other VMware products.

When vSAN iSCSI services were previously announced, I wondered when Windows Server Failover Clusters (WSFC) would be supported. That day is today. This adds to the already existing support for SQL AAG, Exchange DAG, and Oracle RAC. For organizations with WSFC servers in a physical or virtual configuration, vSAN 6.7 supports shared target storage locations when storage targets are exposed using the vSAN iSCSI service.

You can find more information about vSAN 6.7 by checking out Anthony Spiteri’s blog post.

Architecting a vSphere Upgrade

At the time of writing, there are 197 days left before vSphere 5.5 is end of life and no longer supported. I am currently in the middle of an architecture project at work and was reminded of the importance of upgrading — not just for the coolest new features, but for the business value in doing so.

giphy

Last year at VMworld, I had the pleasure of presenting a session with the indomitable Melissa Palmer entitled “Upgrading to vSphere 6.5 – the VCDX Way.” We approached the question of upgrading by using architectural principles rather than clicking ‘next’ all willy-nilly.

Planning Your Upgrade

When it comes to business justification, simply saying “it’s awesome” or “latest and greatest” simply does not cut it.

Better justification is:

  • Extended lifecycle
  • Compatibility (must upgrade to ESXi 6.5 for VSAN 6.5+)
  • vCenter Server HA to ensure RTO is met for all infrastructure components
  • VM encryption to meet XYZ compliance

It is important to approach the challenge of a large-scale upgrade using a distinct methodology. Every architect has their own take on methodology, it is unique and personal to the individual but it should be repeatable. I recommend planning the upgrade project end-to-end before beginning the implementation. That includes an initial assessment (to determine new business requirements and compliance to existing requirements) as well as a post-upgrade validation (to ensure functionality and that all requirements are being met).

There are many ways to achieve a current state analysis, such as using vRealize Operations Manager, the vSphere Optimization Assessment, VMware {code} vCheck for vSphere, etc.

I tend to work through any design by walking through the conceptual model, logical design, and then physical. If you are unfamiliar with these concepts, please take a look at this post.

An example to demonstrate:

  • Conceptual –
    • Requirement: All virtual infrastructure components should be highly available.
  • Logical –
    • Design Decision: Management should be separate from production workloads.
  • Physical –
    • Design Decision: vCenter Server HA will be used and exist within the Management cluster.

However, keep in mind that this is not a journey that you may embark on solo. It is important to include members of various teams, such as networking, storage, security, etc.

Future State Design

It is important to use the current state analysis to identify the flaws in the current design or improvements that may be made. How can upgrading allow you to solve these problems? Consider the design and use of new features or products. Not every single new feature will be applicable to your current infrastructure. Keep in mind that everything is a trade off – improving security may lead to a decrease in availability or manageability.

When is it time to re-architect the infrastructure versus re-hosting?

  • Re-host – to move from one infrastructure platform to another
  • Re-architect – to redesign, make fundamental design changes

Re-hosting is effectively “lifting-and-shifting” your VMs to a newer vSphere version. I tend to lean toward re-architecting as I view upgrades as an opportunity to revisit the architecture and make improvements. I have often found myself working in a data center and wondering “why the hell did someone design and implement storage/networking/etc. that way?” Upgrades can be the time to fix it. This option may prove to be more expensive, but, it can also be the most beneficial. Now is a good time to examine the operational cost of continuing with old architectures.

Ensure to determine key success criteria before beginning the upgrade process. Doing a proof of concept for new features may prove business value. For example, if you have a test or dev cluster, perhaps upgrade it to the newest version and demo using whatever new feature to determine relevance and functionality.

Example Upgrade Plans

Rather than rehashing examples of upgrading, embedded is a copy of our slides from VMworld which contain two examples of upgrading:

  • Upgrading from vSphere 5.5 to vSphere 6.5 with NSX, vRA, and vROPs
  • Upgrading from vSphere 6.0 to vSphere 6.5 with VSAN and Horizon

These are intended to be examples to guide you through a methodology rather than something that should be copied exactly.

Happy upgrading!

VMware Community #vAllStars

On this Thanksgiving Eve in the US, it is easy to recount the things for which I am grateful: my family, my friends, my health, etc. Monday will be 6 years since I exited from my service in the Marine Corps. At that time I was not sure I would even stay in tech as a career (law school still seems like a good backup plan). I am incredibly grateful and humbled by my career and the trajectory it has taken in recent years. A substantial part of this has been involvement in the tech community, especially the VMware community. I’m far from the only person that has built a career on the back of the VMware community. I am thankful for the guidance and inspiration I have received over the past six years.

Read More »

Understanding Erasure Coding with Rubrik

It is imperative for any file system to be highly scalable, performant, and fault tolerant. Otherwise…why would you even bother to store data there? But realistically, achieving fault tolerance is done through data redundancy. On the flipside, the cost of redundancy is increased storage overhead. There are two possible encoding schemes for fault tolerance: triple mirroring (RF3) and erasure coding. To ensure the Scale Data Distributed Filesystem (SDFS, codenamed “Atlas”) is fault tolerant while increasing capacity and maintaining higher performance, Rubrik uses a schema called erasure coding.

Read More »

Understanding MongoDB’s Replica Sets

As a part of its native replication, MongoDB maintains multiple copies of data in a construct called a replica set.

Replica Sets

So, what is a replica set? A replica set in MongoDB is a group of mongod (primary daemon process for the MongoDB system) process that maintains the same data set. Put simply, it is a group of MongoDB servers operating in a primary / secondary failover fashion. Replica sets provide redundancy and high availability.

Read More »

Catch Me at VMworld US 2017!

It’s that time of summer — VMworld US is only a few days away! Yet again I am making the trek to Las Vegas for the festivities. I wanted to highlight the sessions where I will be presenting so that you have the opportunity to either schedule and come heckle or remind yourself to watch later. I will be hanging around the vBrownBag area of VMvillage or the Rubrik booth when not presenting; come say hello!

giphy
jk, I am too pale to be outside in Las Vegas

Read More »

#VirtualDesignMaster Wrap-Up

Part of me feels like it flew by but then I remember the hours spent reviewing all the designs (*ahem* Adam) and then it feels like it took an eternity to get through. Admittedly, Virtual Design Master was probably one of the coolest community driven events in which I have participated. If you are unfamiliar with Virtual Design Master, I strongly encourage you to check out the site and catch up with the five seasons.Read More »