devopsy.kinsta.cloud

Tag: global DevOps

Boots and Sandals: Know the Market

Boots and sandals are basically the same thing—something to protect your feet while you walk about. The thing is that they are intended for slightly different purposes. You wouldn’t wear sandals outside in the middle of a Wisconsin winter*, and you wouldn’t wear boots to your day off, hanging at the beach. The thing is that boots and sandals have been around forever, and it is relatively simple to gauge the merits of each in a given setting. The same is not true of DevOps tools.

Cowboy Boot Sandals.

* Every few years there is a news report about someone found only in sandals in sub-zero weather, they’re not the norm, and there’s a reason they’re in the news.

Rate of Change

The rate at which DevOps markets are maturing is a pace that few enterprises can keep up with. When both development processes and operations processes are changing, new tools are being introduced and the two groups are increasingly working in tandem to support the business, yet another market space is not what they want to study and yet another tool in the tool chain is not something that they want to just “pop in.”

But the DevOps space is young, and there is a lot coming that can help achieve the goals. I have had reason to look into application release automation (ARA), cloud security auditing and global file systems (GFS) in the last few months, and all three bring something to the table in terms of helping IT adapt and automate. The problem is that in each case, the market is a bit muddied. ARA must explain why it does more than Jenkins alone, cloud security auditing must explain why it is better than calling the cloud vendor APIs to do the same task, and GFS must explain why it is more than a cloud storage gateway and how that helps the enterprise.

And they can. But when considering them, you need to do the research and figure out the market and how that market applies to your organization. Which is a bit unfortunate. devopsy.kinsta.cloud and other sites can help by talking about the tools over time, and the vendors’ own promotional pages can help you understand what gap they’re filling, but it’s legwork (though, in many cases, the legwork is worth it). ARA marries app provisioning tools with CI tools, giving a unified workflow, for example. And it makes the deployment process more agile. If you are running many projects that deploy on a regular (not hourly or even weekly, but regular) basis that you may one day want to deploy to a different environment, ARA can help, along with the wealth of other functionality it provides, bridging the two sides of the DevOps coin is probably its largest driver. The same type of thing is possible with the other two toolsets I mentioned, but trying to keep this short enough to read, so will leave it to those interested in GFS or Cloud Security Auditing to research them.

The Key is Knowing Why and Which

In the end, if you’re building out DevOps, you want to automate the process as much as possible. That means as the markets mature, you will want to explore what’s new. These tools can help many organizations provide a smoother or more secure process, but knowing the reason the market exists is the first step, and only then can you decide if you want to evaluate products. They do not all help all customers, so seeing which are right for you—there is no need for either GFS or Cloud Security Auditing if you are a single office with no cloud presence, for example—will help you narrow which toolsets might improve your DevOps efforts.

And whatever you do, don’t buy the “sandal cowboy boot” of IT. It might look good, but won’t be very useful in either of the environments it’s intended for. 😉

— Don Macvittie

April 10, 2017
Are You Paying a ‘Wait-Time Tax’ on Your Global DevOps?
Business increasingly is global, so DevOps has become global as well. In fact, for many enterprises, DevOps entails collaboration between development, test/QA and ops teams across multiple continents.

This is in part due to the economics of IT labor and in part because applications for global enterprises have to be deployed globally.

Unfortunately, enterprises executing DevOps globally must confront the physical realities of global code distribution. And those physical realities impose a “wait-time tax” that fatally undermines Agile processes and culture.

But they don’t have to. There’s a tax-free way to share large volumes of code across globally dispersed DevOps teams.

The Wait of the World

Every time you ship a massive build worldwide, you have to wait. Assume, for example, that you’re sending a 10GB build to five different locations over a 10Mbps MPLS connection. If a couple of your remote locations have 5Mbps connections, it will take them five hours to get each build. But if you have three locations with only 2Mbps connections (as is likely the case in Asia), they will have to wait 12.5 hours.

That wasn’t a problem when you iterated your builds with limited frequency. But as you try to become more aggressive about highly iterative Agile development and testing, this “time tax” becomes punishing.

For one thing, you lose productivity as your overseas developers and test teams wait idly for new artifacts. And these chronic wait times fundamentally undermine the Agile culture you’re trying so hard to build across your organization.

In fact, if your current model for distributing code globally remains as-is, you’ll never achieve the speed and iterative frequency your business needs. And you’ll certainly never come anywhere close to continuous delivery.

Faster Cycles from Dublin to Dubai

Fortunately, you can eliminate DevOps wait times, regardless of how globally dispersed your teams are and how thin their connections to your enterprise network may be.

The solution entails a hub-and-spoke model that:
- Lets you maintain a “gold copy” of your current codebase(s) in the cloud;
- Provides all your remote locations with their own local codebase copies that get continuously and automatically updated with any incremental changes as they occur; and
- Leverages each location’s high-throughput internet connection.
The combination of small, incremental code updates and high internet bandwidth dramatically changes the rules of the global DevOps game, allowing even the most geographically dispersed teams to work with even the largest codebases extremely iteratively and without delay.

It’s difficult enough to sync dev and test teams on different continents. And the pressures on your organization to respond immediately to ever-changing market and regulatory demands will only intensify. So now’s the time to consider abandoning your obsolete approach to global code distribution and adopt a model that better enables you to be fast, super-iterative and global.

— Barry Phillips
January 3, 2017
Salvador Partners Bridges Global Gaps for DevOps

Salvador Partners works on a global scale to help its customers grow their business. The company, which has its own set of products, also focuses on assisting startups in making their vision reality. Indeed, it bills itself as “experts at innovation and exploiting innovation.”

The company started life as a subcontracted electronic components manufacturing company, slowly broadening its lineup to include security products and patents and evolving to become a provider of technology for banking, financial services (fintech), defense and mechanical systems, says Lewis Daniels, founder of Salvador Partners. The company also serves as an incubator and capital arm for new technologies.

Salvador builds circuit boards and technology products, working across artificial intelligence (AI), augmented reality and blockchain technology, together with its other endeavors. Across its projects, wherever software is part and parcel with its products, Salvador Partners’ international team of developers are hard at work.

The firm has built a DevOps culture across its organization despite geographical and language barriers. devopsy.kinsta.cloud explores the Salvador Partners devops culture that works in an umbrella fashion among these international developer groups.

The Global DevOps Culture Challenge

Salvador Partners works with development teams in Russia, China, India, the U.K. and the United States who build software prototypes, which can sometimes prove tricky: There are challenges to getting foreign teams to plug themselves more deeply in to existing domestic teams for future projects. “There’s an obvious value in their experience from the build of your prototype that you then want to tap. The question is whether they want to be a part of your longer-term vision,” Daniels says.

The company also grapples with the location question—whether to consider moving some of its operations to those countries, closer to those teams, or move some or all of them to its domestic operations. “Perhaps the world has become small enough through the use of tools like Slack and [project management] tools that you can let the technology bridge any gaps,” says Daniels. The tools so far have helped disparate development teams make the leap, including addressing any time zone and language issues that appear.

Delineating the Salvador Partners Culture

Salvador Partners uses an agile approach. “If each client wants a unique tweak, we simply badge up a boutique offering where we can innovate, collaborate and deploy in an agile environment to suit the client requirements,” Daniels says.

As development teams work together more frequently, they reuse code and proven approaches more often. “We often find tricks that get carried over to the next application or dashboard,” says Daniels.

Tools are the answer. “Things have changed in recent years. In terms of a culture, I think it’s pretty easy to leverage tools such as Slack and Dropbox to make the team smaller, regardless of where in the world they are positioned,” he says.

Salvador Partners developers also use Trello for sharing project plans and Skype and Uber conference for team collaboration calls. “We use a secure mobile app we developed internally to communicate on some of the new, high-tech or sensitive topics. WeTransfer is also pretty useful for sending larger files,” says Daniels.

Though Salvador Partners looks at its DevOps culture as a whole rather than by region, there are some unique, regional aspects. “We have a real good team based in India and they just go get things done, whereas some of their counterparts we use sometimes get caught up in planning the plans. This can make it difficult to pull a number of pieces of a project together,” says Daniels.

Other Solutions to Challenges

Locations, languages and distances present other challenges as well. Because some projects work with encryption protocols that by law can’t be shared beyond certain countries, the development work can happens only inside the U.K., the United States, Australia, Canada and some European countries, Daniels notes. In these cases, the company simply keeps the work internal, within the countries permitted.

Language barriers can also present issues. “Such was the case where Salvador Partners had Canadian companies working on something and had a French speaker cause a few problems for his English-speaking colleagues,” Daniels says. For language challenges, the company simply whiteboards the project or uses translators.

Time zones can also trip things up. “It creates challenges when you have a New Zealand head office dealing with partners in Singapore and developers in Russia and California. We have had conference calls where participants are going for dinner and at the same time another having their first coffee,” Daniels says.

However, time zones and geographies are less an issue as the available toolsets to solve communications barriers have evolved.

May 13, 2016