Part of making processes more efficient is relying on the crucial component, automation. In DevOps, automation is a near-must for successful performance, because it reduces the number of repetitive tasks thus decreasing the time required for quality results. It is the biggest quality maintainer and speed promoter.
As it’s impossible to automate everything, it’s important to have an automation strategy to get maximum ROI from time and money spent. A properly planned strategy can increase the speed of development and free up teams to concentrate on more essential tasks.
Select the correct cases to automate
What cases do you choose for automation?
Repetitive tests, high-risk cases, large data sets or checks for different browsers and environments?
Well…it depends…on the service you are developing and on your team’s capabilities. The goal is to automate the cases providing the most benefits for the development process and across the entire organization.
Implement automation throughout a sprint
Short release cycles releases can be achieved only if the development and examination are finishedsimultaneously at the end of the sprint. That’s why quality assurance should begin as early as possible. For example, consider unit testing with each build.
Continue to apply automated cases
It is important to build flexible tests because it is inevitable to cases to evolve over time. It may be ideal to write small cases rather than creating cases with dozens of steps at initial implementation. Consider separating test into smaller steps and individually check components rather than an entire app stack.
Types of Tests
Unit testingis the practice of testing small pieces of code, typically individual functions in an isolated manner. If the test uses some external resource, such as a database, it’s not a unit test.
Functional testing is the testing of complete functionality of an application.
As the name suggests, integration testingis testing how parts of the system work together – the integration of the parts. For example, a unit test for database access code would not talk to a real database, but an integration test would.
Unit and integration tests’ results are validated in code, whereas functional test results should be validated the same way as a user would validate it.
Whenever code is modified, even a small tweak can have unexpected consequences. Regression testingensures that a change or addition hasn’t broken any existing functionality. The goal is to catch bugs and to ensure bugs that were eradicated stay that way. As an example, re-running a test scenario that was originally created when a problem was initially fixed can help to validate new changes don’t cause components to fail.
Test Framework
After deciding what types of tests to run, the next step is determining success criteria and then automating the tests. A test framework establishes a set of rules for designing and creating the test cases. Typically, a framework combines practices and tools to increase efficiency.
Consider making the test environment closely resemble customer environments, as well as to accommodate for differences. When testing, ensure to test all options for a particular variable. For instance, when conducting web-based GUI tests, make sure to test all major browsers. Don’t only test with Firefox and call it a day. Don’t forget to test scalability and security.
What is the point of running tests if there are no results? Don’t forget to account with how the metrics are reported.
I am fond of the test pyramid approach popularized by Mike Cohn. The pyramid says that tests on the lower levels are cheaper to write and maintain, and quicker to run. Tests on the upper levels are more expensive to write and maintain, and slower to run. Therefore you should have lots of unit tests, some service tests, and very few UI tests.
Most testing can and should take place during dev by running unit tests after every build. It is easy, cheap, and fast to conduct these tests and it allows for checking work as you go.
After all unit tests pass, move into the component, integration, and API testing phases. These tests validate most logical and business processes without going through the UI. Therefore, it’s recommended to automate these as much as possible.
UI tests run last and least; because these tests are costlier and more difficult, it is ideal to run as few as possible. Consider automating critical tests to remove the human element. From there, complete any manual tests. During this phase, it is critical to design based on user workflow. Start with user login and move forward from there.
If you are still interested in test automation, feel free to check out this corporate blog post I authored.
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.
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.
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?
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.
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.
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.
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.
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.
A server’s capacity can be challenged by database systems with large data sets or high throughput applications. For example, high query rates can consume the CPU capacity of the server; likewise working set sizes larger than a system’s RAM stress the IO capacity of disks.
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 »
This year I am honored to be one of the Virtual Design Master (vDM) judges. If you are unfamiliar with vDM, it is a technology driven reality competition that showcases virtualization community member and their talents as architects. Some competitors are seasoned architect while others are just beginning their design journey. To find out more information, please click here. One of the things that I, along with the other judges, noticed is that many of the contestants did not correctly document conceptual, logical, and physical design.
The best non-IT example that I have seen of this concept the following image:
(Figure 1) Disclaimer: I’m not cool enough to have thought of this. I think all credit goes to @StevePantol.
The way I always describe and diagram design methodology is using the following image:
(Figure 2) Mapping it all together
I will continue to refer to both images as we move forward in this post.
Conceptual
During the assess phase, the architect reaches out to the business’ key stakeholders for the project and explore what each need and want to get out of the project. The job is to identify key constraints and the business requirements that should be met for the design, deploy, and validation phases to be successful.
The assessment phase typically coincides with building the conceptual model of a design. Effectively, the conceptual model categorizes the assessment findings into requirements, constraints, assumptions, and risks categories.
For example:
Requirements –
technicloud.com should create art.
The art should be durable and able to withstand years of appreciation.
Art should be able to be appreciated by millions around the world.
Constraints –
Art cannot be a monolithic installation piece taking up an entire floor of the museum.
Art must not be so bourgeoisie that it cannot be appreciated with an untrained eye.
Art must not be paint-by-numbers.
Risks –
Lead IT architect at technicloud.com has no prior experience creating art.
Mitigation – will require art classes to be taken at local community college.
Lead IT architect is left-handed which may lead to smearing of art.
Mitigation – IT architect will retrain as ambidextrous.
Assumptions –
Art classes at community college make artists.
Museum will provide security as to ensure art appreciators do not damage artwork.
As you read through the requirements and constraints, the idea of how the design should look should be getting clearer and clearer. More risks and assumptions will be added as design decisions are made and the impact is analyzed. Notice that the conceptual model was made up entirely of words? Emphasis on “concept” in the word “conceptual”!
Logical
Once the conceptual model is built out, the architect moves into the logical design phrase (which indicated by the arrows pointing backwards in Figure 2, demonstrating dependence on conceptual). Logical design is where the architect begins making decisions but at a higher level.
Logical art work design decisions –
Art will be a painting.
The painting will be of a person.
The person will be a woman.
For those who are having a hard time following with the art example, a tech example would be:
(Table 1) Logical design decision example
An example of what a logical diagram may look something like this:
(Figure 3) Logical storage diagram example
Notice that these are ‘higher’ level decisions and diagrams. We’re not quite to filling in the details yet when working on logical design. However, note that these design decisions should map back to the conceptual model.
Physical
Once the logical design has been mapped out, architect moves to physical design where hardware and software vendors are chosen and configuration specifications are made. Simply put, this is the phase where the details are determined.
Physical art work design decisions –
The painting will be a half-length portrait.
The medium will be oil on a poplar panel.
The woman will have brown hair.
Once again, if you hate the Mona Lisa then the IT design decision example would be:
XYZ vendor and model of storage array will be purchased.
Storage policy based management will be used to place VMs on the correct storage tier.
Tier-1 LUNs will be replicated hourly.
These are physical design decisions, which directly correlate and extend the logical design decisions with more information. But, again, at the end of the day, this should all tie back to meeting the business requirements.
(Table 2) Physical design decision example
An example of a physical design would be something like:
(Figure 4) Physical storage diagram example
Notice that in this diagram, we’re starting to see more details: vendor, model, how things are connected, etc. Remember that physical should expand on logical design decisions and fill in the blanks. At the end of the day, both logical and physical design decisions should map back to meeting the business requirements set forth in the conceptual model (as evidenced by Figure 2).
Final Thoughts
Being able to quickly and easily distinguish takes time and practice. I am hoping this clarifies some of the mystery and confusion surrounding this idea. Looking forward to seeing more vDM submissions next week.
This post will dive into what is required to build the mentoring relationship. I’m going to take a different approach this time; instead of writing a bunch of paragraphs, I am going to summarize the phases of the mentoring relationship by using an outline. Let’s see how this goes!
At the beginning of the mentoring relationship, the mentor and mentee should discuss how the partnership should be structured. Regardless of whether the mentoring relationship takes a formal structure, there are typically a few phases that take place:
Building rapport
In this phase the mentor and mentee are exploring whether or not they can work together.
Simply get acquainted with one another (number of years in the industry, technical skillset, common skills, similar career paths, etc.)
Determine purpose of relationship and establish expectations.
Active listening, being respectful, being open and honest help build reciprocal trust in this stage.
Setting direction
This phase is all about setting goals. Once there is rapport and the relationship has established its sense of purpose, then determine what should be achieved.
Discuss the overall mentoring goals; for example, the following questions could be asked:
What are your visions and career aspirations?
Where is your career right now?
What are your strengths, weaknesses?
What is your behavioral style?
What is your leadership style?
What are your top three goals?
How can the mentoring relationship help to build new technical skills, explore new ideas, forge a new career path, expand your network, etc.?
If this is a formal mentoring process, a “Mentoring Partnership Agreement” could be established to determine clear goals, roles, and responsibilities, as well as setting a schedule.
Recap and progress
Recap the mentoring sessions at the end of each session. Also consider reviewing the progress between sessions at the beginning of the session.
The progression piece is typically the longest of all the phases. This phase can be perpetual depending on the length of the mentoring relationship.
Work together to accomplish the established goals.
Qualities of a successful mentoring relationship:
Articulation – the mentor should be able to help the mentee articulate their feelings, thoughts and ideas. The mentee may still be learning this skill.
Listening – both the mentee and the mentor should exhibit active listening skills.
Respect – without respect, the relationship will not achieve a level of openness required for successful mentoring.
Goal clarity – both the mentee and mentor need to have a clear understanding of the mentee’s objectives. It would also be good for the mentee to know the mentor’s goals in order for the relationship to be more reciprocal.
Challenging – the mentee and mentor should both be challenged during this relationship.
Self-awareness – the mentor should be proactive and insightful in order to appropriately guide the mentee using his or her own experience. The mentee should be self-aware in order to be able learn from the mentor’s example and advice.
Commitment to learning – both the mentor and the mentee should be learning and growing as a part of this relationship.
Reflection / preparation – a common reason why mentoring relationships fail is because one party or both fails to invest time preparing for or carrying through with the time investment.
TECHNICLOUD 