• Skip to main content
  • Skip to footer

InRhythm

Your partners in accelerated digital transformation

  • Who We Are
  • Our Work
  • Practices & Products
  • Learning & Growth
  • Culture & Careers
  • Blog
  • Contact Us

InRhythm News

Apr 03 2020

Creating Robust Test Automation for Microservices

Any and all projects that a software engineer joins will come in one of two forms: greenfield or legacy codebases. In the majority of cases, projects will fall into the realm of the legacy repositories. As a software engineer, it is our responsibility to be able to strategically navigate our way through either type of project by looking objectively at the opportunities to improve the code base, lower the cognitive load for software engineering and make a determination to advise on better design strategies. But, chances are, there is a problem. Before architecture or design refactors can be taken its best to take a pulse on the health of your platform End to End (E2E). The reason being, lurking in a new or existing platform is likely a common ailment of a modern microservices approach – the inability to test the platform E2E across microservices that are, by design, commonly engineered by different teams over time.

I recently worked on a greenfield platform and nearly 6 months into the project, one of the most critical parts of the project had fallen several months behind from a quality assurance perspective. It was no longer possible for QA to catch up, nor was it possible for QA to engineer and execute E2E testing to complete common user journeys throughout the enterprise system. To solve this conundrum, E2E data generation tools needed to be created so that the QA team could keep upbuilding and testing every scenario and edge case. As I see it, there are three main requirements for an E2E account and data generation tool. The tool should:

1) Create test accounts with mock data for each microservice

2) Link those accounts between up and downs stream microservices

3) Provide easy to access APIs that are self-documenting 

Using a tool like Swagger, QA can use the API description for REST API, i.e. OpenAPI Specification (formerly Swagger Specification) to view the available endpoints and operations to create accounts, generate test data, authenticate, authorize and “connect the microservices”.

By creating tools for E2E testing, our QA team was able to eliminate the hassle of trying to figure out which upstream and downstream microservices needed to be called to ensure that the required accounts and data were available and set up properly to ensure a successful test of all scenarios i.e. based upon the variety of different data types, user permissions, user information and also covering the negative test cases. The QA team was able to catch up and write their entire suite of test scenarios generating the matching accounts and data to satisfy those requirements. The net result of having built an E2E test generation tool was automated tests could be produced exponentially quicker and the tests themselves are more resilient to failure. 

Even though the microservices pattern continues to gain traction, developing E2E testing tools that generate accounts and test data across an enterprise platform will likely still remain a pain point. That having been said, the purpose of this article is to raise awareness. Software Engineering Leadership has an opportunity to step up and ensure that the enterprise system that they look after is healthy E2E. I can’t think of a better way to maintain a healthy system than to ensure accounts and data in the lower environments actually work and unblock testing end-to-end. 

James Woods, Web Engineering Practice Lead

Written by InRhythm · Categorized: Agile & Lean, Cloud Engineering, Code Lounge, InRhythm News, Java Engineering, Learning and Development, Newsletters, Product Development, Software Engineering · Tagged: microservices, testing

Jan 18 2020

Configuration Automation Tools: Orchestrating Your Deployment

“We must accept human error as inevitable – and design around that fact.” – Donald Berwick

Raphael Weaver

In our Technology field, buzz words come and go. One day we’re discussing how databases are the new best thing to the world of Agile Development and the next we see programming languages, frameworks, and methodologies bit the dust like an old western movie.

But one unchanging aspect of technology and its journey is the People who are an irreplaceable part of the creation, the demise, and the popularity of any given technology. This modern-day-world calls for a close to perfection execution, which humans cannot always account for. How does that affect us, the developers and creators, when we are called to building perfect products? 

Removing Human Error

Automation automation automation – and of course throw in some orchestration deployment and configuration management. Leaving the buzz words behind the jest of all of this, “new technology frontier”, is removing human error. This is removing the dependencies of tribal knowledge when it pertains to application and system administration job duties. Those job duties are performed in a repetitive fashion. The job duties are usually consolidated into various custom scripts, leaving a lot of those scripted actions the ability to be boxed up and reused over and over again.

For example, what steps does it take to deploy an application to a server instance? 

  1. Download and Install the various languages and/or framework libraries the application usages.
  2. Download, Install, Configure the Web server that the application will use.
  3. Download, Install, and Configure the Database that the application will use. 
  4. And finally Test to see if all the steps are installed and configured correctly. 

Last but not least run application tests to make sure it is running as expected. Those are the highlight steps for deploying an application to a bare metal, cloud, or virtual server. With a further review, there are numerous upon numerous additional steps. Something simplistic nevertheless highly catastrophic is a possibility of a typo. Consider this case, maybe in this scenario, I meant to type

cd /var/ect/ansible; rm -rf *

but instead I forgot the cd execute command and only ran

rm -rf /

Now my whole drive is erased. Surprisingly enough this can happen quite often even though I am pretty sure the source of truth of my drive is backed up. However, as Murphy Law states, what can happen will happen. And let’s be honest, redoing previous actions that could have been avoided is a down right pain.

No Hidden/Tribal Knowledge

Let’s look back at those steps to deploy an application to an environment. There are a lot of gotchas and/or small intermediary steps involved. For instance, I only listed the high-level steps. I hand these steps to a new engineer or even a junior engineer fresh out of college. The chances are these engineers will have to ask several questions on  “How to”. 

These series of questions will eventually lead to someone like myself saying “just let me do it”. This is how one scenario can lead to years upon years of hidden or tribal knowledge, as one may call it.  To harbor information like a fugitive on the run is getting more and more exposed in the IT/Software industry. The information should be a source of truth maintained in a repository database, that is easy and intuitive to leverage

Implementation Technology Overview

What does that source of truth entail? Can we not skip the documentation of information and go straight into the execution of the steps onto a given system? Or create scripts to reconfigure the application if there was ever a need to? Those questions have been proposed several times and solutions have been formulated several times into the form of extensive and comprehensive build tools/frameworks. These tools are used throughout the industry to solve the problem of orchestrated development, configuration automation and management. 

Furthermore, DevOps tools such as: Chef, Puppet, and Ansible are well mature automation/orchestration tools. Each tool will provide you with enough architecture flexibility to virtually handle any use case you present. Let’s take a slight dive into each one of these technologies.

Puppet

Puppet is the first widely used Configuration Automation and Orchestration software dating back to its initial release in 2005. Puppet uses the Master and Slave paradigm to control X amount of machines. The Ruby language is the script language say, for executing commands in a destination environment. 

The “Puppet Agents”(Slave) are modularized distinct components to be deployed to a server. This can be used for the creation of the server(ie. web server, database, application) in its destination environment.  The Puppet enterprise (Master) is comprised of all the inner workings to manage, secure, and organize agents.

Puppet Architecture

Documentation 
  • https://puppet.com/docs/
  • http://pub.agrarix.net/OpenSource/Puppet/puppetmanual.pdf
  • https://www.rubydoc.info/gems/puppet/ 

Chef

Chef is somewhat similar to Puppet. The core language used within Chef’s abstract module components is Ruby. Chef has several layers of management for your infrastructure automation needs. The Chef workstation is the primary area for managing the various Chef components. The Chef components consist of cookbooks, recipes, and nodes. The naming convention actually follows what you would consider these nouns in cooking to be with technical context of course. 

Recipes are collections of configurations for a given system, virtual, bare metal, or cloud environment. Chef calls those different environments nodes. Cookbook contains recipes and other configurations for application deployment and control mechanisms for the different Chef clients. Lastly, the whole collections of cookbooks are maintained in a Supermarket.

Chef Architecture

Documentation
  • https://docs.chef.io/
  • https://www.linode.com/docs/applications/configuration-management/beginners-guide-chef/ 

Ansible

Ansible is the newest mainstream automation/configuration management tool on the market. Therefore, Ansible uses more modern programming languages and configurations concepts and tools. Python is the programming language used in this framework. One of the modern and fastest up-and-coming template languages is YAML. YAML is programming language agnostic and is a subset of the ever so popular JSON. YAML is used within Ansible to describe an Ansible playbook. 

Ansible playbook contains the steps that need to be executed on a given system. Once the Ansible playbook is intact configuration or further manipulation of the host can be executed through Ansible API – which is implemented in Python. There are several other components within Ansible technology such as modules, plugins, and inventory. 

Ansible Architecture

Documentation
  • https://docs.ansible.com/ansible/2.5/dev_guide/
  • https://devdocs.io/ansible/
  • https://geekflare.com/ansible-basics/ 

Reusability

After covering a couple of the Configuration Automation and Development tools on the market you can see the vast amount of flexibility available in eliminating those repeatable steps from human error. This software’s framework promotes reusable software within an organization – which is the most viable. The ability to scale your application development environment and environmental infrastructure is critical. 

The learning curve may be deeper than using plain old bash scripts but the structure and integrity of using a proven tool and ease of maintenance outweigh the learning curve.

Check it for yourself, reorganize and propel your CI/CD process with Configuration Automation and Orchestrated Deployments and let me know what you think about this article in the comments below.

Raphael Weaver

Sr. Software Engineer

Written by Raphael Weaver · Categorized: Cloud Engineering, InRhythm News, Learning and Development, Newsletters · Tagged: cloud engineering, JavaScript, microservices, scale

Dec 03 2019

Customers are Much, Much More Than Signed Contracts


December 3rd: Customer Collaboration Over Contract Negotiation

Like most things, how you see something is a matter of perspective. The lens that you look through is shaped by experience, environment, who you’re influenced by and the attitude you take towards life and the given topic in particular.

Applying a customer-centric lens to branding, product development and marketing seems like an obvious thing to do, however, it wasn’t until the 1960s when Lester Wunderman urged companies to do so. Moreover, it wasn’t until the turn of the last century when customers took control with their collective new ability to dictate a brand’s narrative via the internet and dawn of social media. So, this concept of customer-centricity, in practice, is actually a modern way of thinking.

“Agile Value #3: customer collaboration over contract negotiation” is an example of a customer-centric approach. However, the core component of the directive is essentially the same. It’s all about communication.

That doesn’t mean unilateral outreach where you as the brand are sending messages, postcards, coupons or holiday catalogues. What it does mean is creating a forum for open dialogue in the spirit of true communication where conversations are bilateral. Doing so ensures that pain points can be discussed until they are understood and then resolved.

As agile product developers, the responsibility of maintaining a health dialogue with our customers is up to us. All too often, I have heard software engineers citing that communication with a client is the responsibility of the sales and marketing team. Not so!

We’re the people who are typically onsite with the customer. It is up to us as the agile craftsmen to deliver our best work to our clients so that their light can shine brightly. Clients look to us as their trusted advisors who are there to help them meet their needs, deliver quality work on time and help ensure our client’s success with their customers. Losing sight of the value of wearing a customer-centric lens compromises our ability to deliver our best for our clients. As soon as we we make it about ourselves and not our clients, the work environment will become more challenging and potentially even toxic.

The concept of collaboration over contract negotiations delineates the difference of being regarded as a vendor versus as a partner. Here at InRhythm, we know which side we aim to be on. Approaching software engineering with agile methodology requires that we are constantly communicating with our clients, assessing their needs and anticipating their needs even before our clients realize that things have shifted.

This brings us back to perspective. If we communicate regularly, with transparency, and deliver quality work in a timely manner, our clients will view us with the lens of partnership. Conversely, if we view our clients with the lens of a signed contract and the dollars tied to it, our perspective will be tarnished. As software engineers, we will struggle to deliver our work with that passion and quality that is required to fulfill the demands of an agile effort.

Agile Value #3 is the reminder for all of us that the lens that we view our work with is critically important. Viewing our deliverables and efforts with a client-centric perspective will positively impact how they view us. And, it can make all the difference between doing business versus being out of business.

Thanks and Keep Growing,

Gunjan Doshi

CEO, InRhythm

What We’re Reading Around the Web

The Real ROI Of Being Customer-Centric
Entrepreneur
“No business will survive long without satisfying its customers. That much should be evident to any company whether it is established or just starting out.”

100 Of The Most Customer-Centric Companies
Forbes
“Customer-centric companies live and breathe their customers and are laser-focused on providing amazing experiences.”

Customer Centricity — Marketing as customer-centric corporate management
Medium
“[The] key to success: a more radical focus on humans. Genuine customer centricity requires to rethink all functions and levels.”

6 Ways to Build a Customer-Centric Culture
Harvard Business Review
“To successfully implement a customer-centric strategy and operating model, a company must have a culture that aligns with them — and leaders who deliberately cultivate the necessary mindset and values in their employees.”


Written by Gunjan Doshi · Categorized: Customer, InRhythm News, interviewing, Newsletters · Tagged: agile, CEO, coaching, customer-centric, engineering, gunjan doshi, inrhythm, insights, networking, product development, software, tech, tips

Oct 23 2019

We are the Living Lab: InRhythm’s Learning and Growth Newsletter


October 22nd: Agile Craftsman in a Living Lab

For more than 15 years, InRhythm has been in the business of practicing agile methodology, building high velocity teams and accelerating product development through a combination of staffing solutions, processes and tools. We’re agile craftsmen, constantly learning, testing new ideas and sharing what we’ve learned or developed with our partners. In essence, we are a living lab for agile best practices.

Going forward, our Learning & Growth newsletter and InRhythm blog will highlight agile values and principles through examples to demonstrate how we are putting each of the values and principles into action. As agile craftsmen, it is imperative that we assess every process and method with a lens designed to identify inefficiencies. When recognized, these opportunities for improvement must be raised and discussed as a team to uncover ways to address the inefficiencies.

Within our own walls at InRhythm, we analyze processes to learn why they work – and why they don’t. Learning by doing is often the best form of instruction. Agile craftsmen must recognize that there is the potential to fail and “feel the fear but do it anyway” in the words of Coach Jeffers. 

Our practice leads scrutinize each effort at each partner and bring back new ideas and best practices. Internally, we test these new concepts, practice implementing and executing them then review what we did with a lens on how to make it better. By first testing new ideas ourselves, we can assure our partners that we are bringing vetted concepts forward to make their high velocity teams even stronger. As a living lab of agile craftsmen, we cannot be afraid to pivot.

Inherent in our success is learning, learning through observation, application and implementation. What doesn’t work within our own walls is unlikely to work at a partner site. Recognizing the difference between an agile concept that has the potential to be beneficial once artfully defined and practiced versus a concept that is flawed in its conception and will never work despite excellent execution can only be done through trial and error. 

A hallmark of agile product development and of high velocity teams is failing fast. However, in order to fail, you first need to try. Wayne Gretzky, a hockey legend, masterfully articulated this his popularized quotation, “You miss 100% of the shots you don’t take.”

Over the weeks and months ahead, we look forward to sharing some of our “experiments” as agile craftsmen practicing new concepts to make the available to you and our partners.

I’m interested to learn how have you been able to apply internal learnings to your business success, and create your own living lab? Share your thoughts with @GetInRhythm or on the InRhythmU blog.

Thanks and Keep Growing,

Gunjan Doshi

CEO, InRhythm

What We’re Reading Around the Web

What is Agile Testing?
Guru99
“Agile Testing can begin at the start of the project with continuous integration between development and testing.”

Engineering Higher Quality Through Agile Testing
Atlassian
“Project owners face an unwelcome choice: delay the release, or skimp on testing. (I’ll give you one guess as to which option wins 99% of the time.)”W

Agile Testing, Principles & Advantages
ReQtest
“Agile testing not only facilitates the early detection of defects but also reduces the cost of bugs by fixing them early.”

Agile Methodology: The Complete Guide to Understanding Agile Testing
RTricentis
“This frequency has forced testers to shift when they conduct testing, how they work with developers and BAs and even what tests they conduct, all while maintaining quality standards.”


Written by Gunjan Doshi · Categorized: InRhythm News, interviewing, Newsletters · Tagged: 10x teams, agile, gunjan doshi, high performance culture, inrhythm, learning and growth, management consulting, newsletter, organizational assessments, performance, process

Oct 11 2019

Achieving High Performance Cultures: InRhythm’s Learning and Growth Newsletter


October 8th: How to Achieve High Performance Cultures

Everyone wants a high performance culture. Here’s why it matters. Research shows that high performance organizations have a 14% job turnover rate compared to 48% as seen in low performance organizations. 

Throughout nearly 20 years of management consulting, I’ve completed over 100 organizational assessments of companies ranging from startups like Yodel and Vimeo to great enterprises like Consumer Report and Amazon. These assessments revealed the reasons why companies struggle to attain high performance cultures. Additionally, these evaluations highlighted how investments in team culture enabled transformation into successful enterprises. 

The key message is that high performance cultures require what we refer to as “10x teams.” Success of 10x teams is not the result of a secret formula. Rather, it’s based on an approach that can be consistently repeated.

That said, one of the main roadblocks to developing 10x teams is the process itself. Furthermore, the obsession with process. There is a preconceived notion that adoption of a process, whether it be agile development, safe or lean mindset, or some other process, will solve every problem. Not so. 

Working with my clients has illustrated that it is the convergence of people, culture, process and business structure that spurs the magic. Ultimately, it is this convergence that creates 10x teams and high performance cultures. The adoption of key practices accelerates performance improvement. These practices include pulling group members together, propelling groups into action, encouraging groups to push boundaries as a team so that they can achieve an increasingly greater impact together over time.

Off-the-shelf processes for 10x team transformation simply do not exist. Bespoke processes must be developed based on your people, culture, org structure, geography and so on. Efforts to design a process in the absence of these factors typically have the reverse effect: your business will slow down and you typically will not achieve the desired outcome. Additionally, unintended consequences include expectations for a transformed culture which is unattainable with a vanilla approach. Confusion and dissatisfaction often result.

Without a doubt, based on my experience, adopting a generic process that does not factor in the aspects unique to your business is the number one reason teams are prevented from becoming 10x. Another important consideration is that team transformations are dynamic processes which are either cumulatively additive or negative. Given that the long-term goal is a sustainable culture, continuous adaptation is required to keep your teams and company moving in the right direction. 

I’m curious. How has process limited your organization from growing and what barriers have you come across along the way? Share your thoughts with @GetInRhythm or on the InRhythmU blog.

Thanks and Keep Growing,

Gunjan Doshi

CEO, InRhythm

What We’re Reading Around the Web

Why Some Rules are more likely to be Broken
Harvard Business Review 
“Our intuition was that rules that were high in either type of complexity would be harder to follow. Because organizations rely on routines for following rules, complex rules would require complex routines, which would be harder to execute reliably.”

5 Team Attributes that are Killing Your Creative Tension
WForbes
“Fear of failure can stifle the engagement, speaking up and risk taking that are hallmarks of creative thinking.”

Companies do Best when they Encourage this Kind of Culture
Forbes
“Businesses do best when they’re built around high-purpose cultures, which are equally focused on both employees and customers.”
 


Written by Gunjan Doshi · Categorized: InRhythm News, interviewing, Newsletters · Tagged: 10x teams, agile, gunjan doshi, high performance culture, inrhythm, learning and growth, management consulting, newsletter, organizational assessments, performance, process

  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Interim pages omitted …
  • Go to page 21
  • Go to Next Page »

Footer

Interested in learning more?
Connect with Us
InRhythm

140 Broadway
Suite 2270
New York, NY 10005

1 800 683 7813
get@inrhythm.com

Copyright © 2022 · InRhythm on Genesis Framework · WordPress · Log in

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Cookie settingsACCEPT
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Non-necessary
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
SAVE & ACCEPT