Cloud4C is collaborating with Google Cloud to build a Centre of Excellence (CoE) for SAP and Anthos by Google Cloud. The partnership aims to enable enterprises to accelerate their digital transformation journey on the cloud.

The center of excellence (CoE) will equip businesses with capabilities to modernize mission critical IT infrastructure and applications, while gaining the complete benefit of Cloud4C’s extended SAP service portfolio. By leveraging Anthos, enterprises can modernize their existing applications and build cloud-native apps to achieve agility and cost savings with Google Cloud.

Sridhar Pinnapureddy, Founder and CEO, Cloud4C, said, “We are delighted to collaborate with Google Cloud. Our customers can leverage the best of Google’s offerings in a secure manner with reduced capital investment and improved value delivery. The CoE will serve as a multi-disciplinary customer showcase hub, developing and delivering solutions for high efficiency and reliability.” He further added, “Rapid deployment of SAP applications through Anthos by Google will additionally contribute to lowering carbon footprint.”

The CoE will also support customers in their modernization journey, as they level up their mission-critical IT infrastructure and applications and leverage advanced Google Cloud Artificial Intelligence (AI), Machine Learning (ML) and analytics capabilities at scale. The partnership will help organizations make the most of Cloud 4C’s end to end SAP capabilities through multi-cloud support, multi-cluster/unified management, centralized policy management, infrastructure management and achieve higher return on investment, enhanced platform, operational efficiency, rapid scalability and optimize costs.

“Together with Cloud4C, we will offer organizations a clear path to build, run, and manage their critical SAP workloads on hybrid and multi cloud environments with full flexibility, agility and security. This will be a huge benefit for businesses in India,” said Amitabh Jacob, Head of Partners and Alliances, Google Cloud India.

Cloud4C is the largest and the oldest SAP Partner offering SAP Managed Services across 25 countries and 50+ locations and has dedicated SAP services including Switch2Cloud, S/4 HANA implementation and application management services, exclusively focusing on greenfield, brownfield and hybrid packages as well as end to end application management services (AMS) offerings.

Oh, well, 2020 was a long year, wasn’t it? Thanks (or actually, not at all) to the Covid-19 pandemic, the order of the world has changed, and how! Economies have stagnated, consumers have adapted, and businesses have pivoted. Now, we’re all just learning how to embrace what has changed.

Ever since the nation went into lockdown, millions of professionals in India have had the chance to take some bold calls, the most liberating of which, has been to take a plunge and startup on their own. Be it out of a passion for some, out of having some extra hours in the day from working remotely, or for having figured out a need in the market for the others — when it comes to building a business, taking the early steps right is everything.

However, when it comes to funding, it’s a long haul from the day you start your company to the day you’re able to bring investors in through the front door. For bootstrapped founders, optimising company resources and costs becomes as important as executing things well.

Hence, the need of the hour for such businesses is to realise the importance of technologies like cloud computing in solving their challenges to lay a strong foundation and help them build and scale their business in a highly sustainable way. In this quick article, we’ll double down on how cloud computing becomes a no-brainer to look towards for any founder when starting out.

Typical Challenges Of A Startup Founder
Running a business is tough, and starting a business is even tougher. Startup founders, across the board, unanimously, are overwhelmed with challenges and troubles. From not having industry-specific knowledge and expertise to not knowing how to manage finances, they seem to go through it all. Here are some of the typical challenges faced by a startup founder:

Exponentially Increasing Cost Of Development: If you’re starting out in 2020, there’s an almost one hundred per cent chance you’re building a business which sells products or services over the internet. In which case, as your business grows, you need to keep expanding your app or website to be able to facilitate the uptick in traction. This means more server space, complex compute options, managed databases, you name it. Not hard to guess what all of this translates to higher costs.
Lack Of Robust Infrastructure To Scale Up Offerings: Whether it is out of ignorance, or negligence, a big challenge that startups face during their course is not having a tech infrastructure which can enable them to execute their roadmap. As a result of which, considerable time and money are spent to make things right.
Filtering Good Advice From All The Noise: If you’re a non-tech founder, for you, this could simply be knowing how tech works. And when you get to learn more about it, it can be difficult to cut through the clutter, to filter out good advice from the noise. Which is why it’s always better to follow advice which comes with proof.
Let’s see how using cloud computing can help you steer clear of these challenges, but first, here’s a quick introduction to cloud computing for the uninitiated.

So, What Is Cloud Computing?
While it’s been more than two decades that cloud computing has now been on the technology scene, there’s still a lot of confusion around what it constitutes. Simply put, cloud computing is the delivery of computing services — including servers, storage, databases, networking, software, analytics, and intelligence — over the internet, called here as the cloud, to offer increased flexibility of resources, lower infrastructure costs, and improved the ability to scale.

The Benefits: Why Should Startups Consider Cloud Computing?
Despite data pointing to the business efficiencies, cost-benefits, and competitive advantages it holds, cloud computing hasn’t fully caught up with the startup community. According to a report, businesses that invest in new-age technologies like cloud computing, marketing automation and more, enjoy 53% higher revenue.

Shouldn’t it then be obvious for you to choose cloud as the de-facto infrastructure? Here is a look at some of the tangible benefits Cloud Computing can provide for your startup:

Improves Agility And Speed Of Execution
One of the most apparent benefits of working in a cloud computing environment is this: new development resources are always only a click away, as opposed to having on-site servers and infrastructure, which can sometimes take weeks to provide. Owing to this, there is a dramatic increase in the agility and speed of execution for your business since the cost and time it takes to develop is lowered by a significant margin.

Offers Flexibility According To Your Needs
Cloud helps you eliminate guesswork from your infrastructure capacity needs, while at the same time making it more flexible for you to experiment and make iterative decisions. When you make a decision prior to deployment, you often end up either holding on expensive unused resources or dealing with limited capacity. With cloud computing, these problems go away for good. From dynamic compute power to storage, the cloud offers you complete flexibility in choosing the right amount and type of resources for your stack.

Keeps Development Costs Affordable As You Scale
More than 20% businesses are concerned about the cost of setting-up cloud infrastructure and other resources as opposed to having on-site servers, however, this is just a misconception as cloud computing needs minimum investment to get you started. Moreover, you can pay only for actual usage of resources and increase your investments as you scale your products or offerings.

Provides Enterprise-grade Data Security And Protection
According to RapidScale, 94% of businesses saw an improvement in security after switching to the cloud, and 91% said the cloud makes it easier to meet government compliance requirements. By locating data on reliable servers, providing encryption, and making regular backups and snapshots, the majority of cloud infrastructure providers provide a set of services and technologies which help to protect your company’s data very securely.

How Startups Have Leveraged Cloud Computing Successfully
Now that we’ve addressed the obvious, and not so obvious benefits of cloud computing for startups, let’s look at some testimonials from startups who have leveraged it successfully.

Slack Practices Disaster Recovery Scenarios Through Cloud
In case you haven’t heard the name, Slack is a collaboration tool which provides a messaging platform that integrates with and unifies a wide range of apps and services such as Google Docs, Jira, GitHub, MailChimp, Trello, Stripe, and more.

The ease of provisioning resources in the cloud allows Slack to practice disaster recovery scenarios, which is essential for assuring existing and prospective customers that their information will always be there, when and where they need it.

Moreover, being on cloud immediately addresses their customers’ security concerns because their cloud provider, AWS, publishes service organisation control (SOC) reports, which are based on third-party examinations evaluating how AWS achieves compliance controls and objectives.

Ralali Scales And Grows Exponentially With Cloud
Ralali is an online B2B marketplace in Indonesia. It connects local sellers and buyers, from industrial and maintenance, repair, and operating categories to office supplies, automotive, medical, agriculture, and many others.

Since using cloud services, Ralali’s agent business has been able to grow from 400 agents to over 100,000 agents in a year. Ralali.com has been able to innovate and start new projects in under 3 days, scaling quickly to provide highly available services for its end users.

ShopBack Cuts Infrastructure Costs by 60%
ShopBack is a cashback reward program available across Asia-Pacific with over 5 million members on its platform. It allows online shoppers to receive a small percentage of their purchases on the platform, paid for through affiliate programs by the merchant.

Looking for cost reductions as well as improved scalability and reliability, ShopBack discovered a cloud solution to reduce its infrastructure costs by 60 per cent, increased app/site usage fourfold, and more.

What To Keep In Mind When Choosing A Cloud Solution For Your Startup
With the plethora of tools out there, it can be a tad bit difficult to figure out how to choose the one which is most appropriate for your business. Choosing the right cloud computing is not just important, but paramount to the success of your startup. Here are few things you need to keep in mind when choosing a cloud provider. It should:

Be Robust Enough To Support Your Ambitions
Whether it is building, growing, or scaling, your cloud provider should be able to support you at all stages of your startup’s journey. Given that providing services and infrastructure is only a part of it, your cloud services provider should also be able to offer you resources and community so you can learn from how others have been able to fix the problems you have.

Offer Round-The-Clock Troubleshooting And Support

Another parameter which requires you to make a careful consideration is customer support. If you’d need assistance, and you surely would especially in the young days of your startup, would you be able to get it quickly, and on the channel of your preference?

In some cases, customer support is only provided through chat service or call centre. For the hustle at which startups operate, this might not be the most ideal for you. What you should look for is having a dedicated resource, in addition to having the usual channels. Chances are you still might encounter some constraints on the time and access, so be sure to clear all your queries upfront with regards to the level and form of support you’d be provided with.

Integrate Well With Your Tech Stack

As your startup grows, you’d need more and more tools to empower your teams and various business functions for them to improve productivity, automate tasks, streamline processes, and whatnot. Decisions like tech infrastructure and hosting are some of the most critical ones you’d make in your startup journey, hence, it becomes imperative for you to choose a cloud provider that offers native integration (or through APIs) to other market-leading products.

As a founder, and a business professional, you’d be well versed with the concept of investment vs expense. Investments are what help you grow, expenses are what you’d rather not have on your plate if there was a choice. Cloud is akin to having a solid investment.

To reiterate the point of this article, if you have a good foundation on which you’re trying to build your startup, your chances of success increase tremendously. Otherwise you’d just be the 9/10 that fail despite doing most things right.

If you are thinking about career goals for 2021 and looking at various certifications, consider spending that time and energy on volunteering time instead. Recruiter Taylor Desseyn often recommends that job seekers spend time contributing to open source projects instead of completing certifications. He thinks the ROI of writing code is higher and creates an edge in the hiring process.

“Take the time you are going to invest in a certification and take on free work and get that work in your GitHub,” he said. “What I’ve seen from employers is they would rather see real world work experience than a piece of paper.”

Leaders in the open source community back up that idea.Todd Moore, IBM’s vice president of open source, said code posted on GitHub becomes part of a developer’s resume.

“Code talks for itself,” he said. “You also can help with code reviews because making suggestions is a huge part of the open source process.”

Here is some advice from experts about how to start contributing code and volunteer time to the open source community and

Getting starting with GitHub

Sachin Gupta, HackerEarth’s CEO and co-founder, recommended starting small when picking an open source project to work on.

“It’s not recommended to pick up the big and famous projects because the scrutiny there is higher and the chances of your commits being accepted in the beginning are low,” he said. “Start with something as basic as contributing to documentation, patching a simple bug, or fixing comments.”

SEE: Top 5 programming languages for systems admins to learn (free PDF) (TechRepublic)

This helps someone new to open source start making contributions without the risk of the pull requests being rejected.

“Once a few contributions are accepted, you build confidence and demonstrate ability, which can create a feedback loop of success,” he said.

Gupta also recommends pushing side projects to GitHub, including any code written outside of work.

“One easy way to build out a Github profile is to participate in hackathons and push all your hackathon projects to Github,” he said. “It’s a great way of demonstrating skills to recruiters and hiring managers, and building your own coding skills.”

Some developers build out a simple resume using Github pages. Another option is to call out key GitHub contributions such as repos, stars, and commits on a traditional resume. Gupta also suggests linking your Github profile to other online developer profiles.

“These profiles help to merge specific experience with skills that can be quantified and more easily assessed,” he said.

Open source contributions and the hiring process
Gupta said that activity in the open source community does help hiring managers understand experience level and proficiency.

“For example, the types of repos that you have committed to show the complexity of the tasks you can complete, the frequency of contribution indicates your commitment to certain activities and whether you have a long-standing base of experience, and the languages/tech highlights your proficiency in certain types of skills,” he said.

Gupta said that developers who participate in hackathons at HackerEarth often submit their prototypes on Github, which illustrates a person’s ability to understand real world problems and tech integration capabilities.

Gupta also said that having prior information about a candidate’s Github projects can help hiring managers conduct better interviews.

“For instance, I could take a code snippet from their Github projects and use our interviewing product, FaceCode, to do a more meaningful pair programming interview based on the skills they demonstrate in that public forum,” he said.

Moore said that developers looking for a new job should look for companies that encourage employees to contribute to open source projects.

“GitHub works for everybody because it’s a virtuous cycle—it helps the community and helps your career,” he said.

Other ways to contribute to the community
Brendan O’Leary, GitLab senior developer evangelist, said that contributing code is only one of many ways developers can contribute to open source and gain meaningful experience.

“New developers have a unique position to take a look at documentation, READMEs, and other material outside of code with a fresh perspective and deliver value in contributions there,” he said.

O’Leary also recommends that developers who are early in their careers document their learning process by writing a blog post or making a video about a new skill.

“Not only will this cement your own knowledge, but it will also help others too and give you a chance to show off your ability to learn, which is one of the most critical skills for any software engineer,” he said.

O’Leary said that these contributions are still worthwhile, even though this kind of work doesn’t show up on a contribution graph.

SoftServe, a leading digital authority and consulting company, announces it has achieved Premier Consulting Partner status in the Amazon Web Services (AWS) Partner Network (APN). The APN Premier Consulting Partner status differentiates SoftServe as an APN Partner that demonstrates expertise and notable success in helping customers design, architect, build, migrate, and manage workloads on AWS.

We are committed to our clients’ success in realizing the advantages of AWS to transform and future-proof their business, delivering end-to-end solutions that solve complex enterprise challenges while enhancing speed, agility, and scalability,” said Andrew Greene – Associate Vice President, Global Partnerships & Alliances at SoftServe. “We are excited to join the ranks of APN Premier Consulting Partners who have proven expertise at the highest level with the breadth of services and pace of innovation of AWS.”

To become an APN Premier Consulting Partner, companies must complete a rigorous approval process through accreditations and certifications; demonstrate a long-term investment in their relationship with AWS; and have extensive expertise in deploying customer solutions on AWS. APN Premier Consulting Partners also have a strong team of AWS Trained & Certified technical consultants and have deep expertise in project management and professional services.

SoftServe holds AWS DevOps, SaaS, Data & Analytics, Retail, and Financial Services Competencies. The company’s AWS solution areas span healthcare, financial services, retail, energy, and high-tech ISV industries; and with specialized teams of solution architects, big data engineers, and data scientists, SoftServe can guide customers to achieve Cloud success across the full spectrum of AWS Cloud services, workloads, and customer use cases.

Get the most from your AWS investments with speed, agility, and scalability to decrease time to Cloud value while ensuring your projects are deployed on time and on budget. Visit SoftServe’s AWS page to get started today.

SoftServe is a digital authority that advises and provides at the cutting-edge of technology. We reveal, transform, accelerate, and optimize the way enterprises and software companies do business. With expertise across healthcare, retail, energy, financial services, software, and more, we implement end-to-end solutions to deliver the innovation, quality, and speed that our clients’ users expect.

SoftServe delivers open innovation—from generating compelling new ideas, to developing and implementing transformational products and services. Our work and client experience is built on a foundation of empathetic, human-focused experience design that ensures continuity from concept to release. We empower enterprises and software companies to (re)identify differentiation, accelerate solution development, and vigorously compete in today’s digital economy. No matter where you are in your journey.

What Is a Next-Gen WAF and Why Does It Matter for DevOps?

Traditional Web Application Firewalls (WAFs) were designed primarily as perimeter defenses—statically configured rule sets that inspect HTTP traffic and block suspicious requests. While effective in narrow scenarios, legacy WAFs are often criticized for being opaque “black boxes” that block requests without surfacing contextual information about why a request was flagged. This lack of visibility is a poor fit for modern DevOps practices, where speed, feedback loops, and observability are foundational principles.

A next-generation WAF addresses these shortcomings by operating as an integrated security data layer rather than a standalone gate. Instead of just blocking traffic, it collects Layer 7 (application-layer) telemetry, exposes that data through APIs and integrations, and feeds actionable intelligence back into the tools that development, security, and operations teams already use.

Security Visibility at Every Stage of the DevOps Lifecycle

The DevOps lifecycle is typically broken into continuous stages: Plan, Code, Build, Test, Release, Deploy, Operate, and Monitor. A next-gen WAF can contribute meaningful security signal at each of these stages—not just at the perimeter in production. The sections below outline where and how that value is delivered.

Code: Surface Real-World Vulnerabilities for Developers

Static analysis and code review catch many issues before deployment, but they cannot fully replicate the conditions of production traffic. A next-gen WAF observes how attackers actually attempt to exploit your running application and can surface patterns that indicate high-value security bugs—such as injection attempts repeatedly targeting a specific endpoint. This gives developers a prioritized, evidence-based list of vulnerabilities to address in the next sprint rather than relying solely on theoretical threat models.

Build: Visibility Into Cloud-Native Attack Surfaces

Modern cloud-native applications—deployed across microservices, containers, and managed platforms—introduce web-layer attack surfaces that traditional network controls do not adequately cover. Cloud providers offer robust infrastructure security, but application-layer visibility is typically the team’s own responsibility. A next-gen WAF deployed alongside cloud-native workloads provides that missing layer of context, enabling security and platform teams to understand the real-world threat landscape their architecture faces before a vulnerability becomes an incident.

Release: Protection Without Code Changes on Every Deployment

DevOps teams release frequently—often multiple times per day. Requiring a manual security review or configuration change on every release is a bottleneck that directly conflicts with continuous delivery. A next-gen WAF solves this by decoupling application security from the release artifact itself. Whether deployed as a sidecar agent, a reverse proxy, or a cloud-delivered WAF service, protection travels with the infrastructure configuration rather than the application code. Teams can release confidently knowing their WAF policy follows the deployment automatically.

Operate: Production Monitoring on Key Application Metrics

Operations teams are responsible for availability, performance, and reliability. Security events—such as a volumetric request flood or a spike in invalid authentication attempts—directly threaten these objectives. A next-gen WAF contributes to operational observability by exposing security-relevant metrics alongside standard application performance indicators. When operations teams can see attack patterns and application health in a unified view, they can respond faster and make more informed decisions about scaling, rate-limiting, or incident escalation.

Monitor: Real-Time Alerting and Integration With Your Toolchain

After deployment, continuous monitoring is essential. A next-gen WAF integrates with the broader security and DevOps toolchain—sending alerts and telemetry to SIEM platforms, incident management systems, messaging tools like Slack or PagerDuty, and monitoring dashboards—so that security signals appear in the same places where teams are already working. This removes the need to context-switch into a separate security console to understand what is happening in production.

Next-Gen WAF as a Force Multiplier for Security and DevOps Teams

Security and DevOps teams are almost universally resource-constrained. A next-gen WAF can operate in two complementary modes that reflect different team maturity levels:

• Automated protection mode: Teams that need immediate coverage without deep customization can rely on the WAF’s automated detection and blocking capabilities. This allows smaller teams to maintain a strong security posture without dedicating significant engineering time to rule tuning.
• Intelligence and KPI mode: More mature teams can treat the WAF as a security data source, using its management console and API to extract KPIs, analyze attacker behavior, and feed that intelligence back into their development and security processes. This produces compounding improvements in application security over time.

Key Capabilities to Look for in a Next-Gen WAF

When evaluating next-gen WAF solutions for a DevOps environment, prioritize the following capabilities:

• API-first architecture: Security data should be accessible programmatically so it can be integrated into pipelines, dashboards, and automation workflows.
• Flexible deployment models: Support for agent-based deployment, reverse proxy, and cloud-delivered WAF ensures the solution fits different infrastructure topologies.
• Contextual blocking decisions: Every block or flag should include enough context for a developer or analyst to understand and act on the decision.
• Native integrations with DevOps tooling: Pre-built integrations with CI/CD platforms, monitoring systems, SIEM tools, and communication platforms reduce integration effort.
• Low false-positive rate: In a continuous delivery environment, a WAF that generates excessive false positives will be bypassed or disabled. Accuracy is a prerequisite for adoption.
• Support for modern traffic patterns: The solution should handle REST APIs, GraphQL, gRPC, and other contemporary application protocols in addition to traditional web traffic.

Summary

A next-generation WAF is not simply a more powerful version of a legacy firewall. When properly integrated into the DevOps lifecycle, it becomes a source of continuous security intelligence that informs coding decisions, validates builds, protects releases, supports operations, and feeds monitoring workflows. For teams practicing continuous delivery, the ability to decouple application security from the release artifact—while maintaining full observability of the production threat landscape—is a meaningful operational advantage.

If you are evaluating next-gen WAF options for your organization, focus on solutions that expose their data through open APIs, integrate with the tools your teams already use, and are designed from the ground up for cloud-native and containerized environments.

Although most developers use GitHub to organize and share open-source code, funds like Coinbase Ventures, Distributed Global and Digital Currency Group are betting on a crypto-native alternative.

Former ConsenSys token guru Harrison Hines is now CEO of his own startup, Terminal, which closed a $3.7 million seed round in late 2018 for a developer hub specifically built for decentralized apps (dapps). The hub quietly went live over the summer and is undergoing a soft launch this week.

Unlike the Microsoft-owned GitHub, which requires a quick workaround in order to use smart contracts, Hines told CoinDesk Web3 developers will be able to deploy software directly from the Terminal platform. Projects like MakerDAO stablecoin loans rely on smart contracts (software that automatically executes business logic) to safeguard hundreds of millions of dollars worth of cryptocurrency.

“For a large ecosystem like MakerDAO with tons of smart contracts live, Terminal allows us to curate starting points for developers tailored exactly for their needs,” MakerDAO engineer Vamsi Alluri told CoinDesk.

Terminal CTO Janison Sivarajah told CoinDesk this platform was designed for Web3, the shorthand for an internet populated by applications that aren’t hosted or controlled by a single entity.

“Once that smart contract is actually deployed on the blockchain, it is a live object that lives on one of these decentralized protocols,” Sivarajah said. “People need an interface to surface them, view data about them and interact with them. You can’t do that on GitHub.”

Terminal also offers limited node services, for free, and direct conduits to external infrastructure providers like Infura or BlockCypher.

Stepping back, ethereum fans generally use “infrastructure” to mean an external party running nodes and offering blockchain data as a service. Unlike bitcoin, which has plug-and-play hardware node options, most experts agree it is cumbersome to run an ethereum node with full archives. In order for dapps to take off and hit the mainstream, token connoisseurs say, the industry requires more independent node operators and easier access to node data.

“You have to run nodes across all those [testing, production, etc.] environments,”  Sivarajah said. “Someone could use the hosted nodes that we provide … because that’s a lot cheaper and easier to get off the ground. But then you can point the production environment to your own infrastructure.”

To be clear, Terminal isn’t looking to compete with ConsenSys-owned API provider INFURA, which served 5,000 daily users as of July 2019, according to INFURA product manager Michael Godsey. Hines told CoinDesk his legal complaint against ConsenSys founder Joseph Lubin, alleging the former employer owed Hines $13 million in unpaid profits and benefits, was resolved amicably out of court.

“We are planning to, hopefully, get every ConsenSys project onto Terminal and using Terminal,” Hines said. “I do think there are opportunities for us to work with several of them in the future.”

Growth plans

Terminal’s freemium business model is predicated on the hope that, like GitHub, some developers will eventually pay for premium support services.

“Alerting and notifications are just one feature in Terminal, but it is a feature we have been exploring the most to assist 0x developers,” engineer Jacob Evans, of the exchange startup 0x, told CoinDesk. “Terminal also has a number of great features that will help support developers at the prototyping and hackathon stage. It’s critical that developers can play around and experiment efficiently.”

With regards to such experiments, Sivarajah said Terminal is running roughly seven different nodes to support projects using blockchains like xDAI, Rootstock and POA, in addition to private testnets.

“A contract on ethereum can easily be deployed on any of the other networks that use the EVM [ethereum virtual machine] blockchain,” Sivarajah said, estimating two-dozen networks currently use the EVM. “We will also see which other frameworks are gaining traction.”

Traction will be the deciding factor. Dapp.com data suggests no ethereum-based dapp currently attracts more than 2,000 daily users.

If you build it, will they come?

From the perspective of Distributed Global partner Johnny Steindorff, a Terminal investor, part of this relates to how much manual work is required to maintain reliable Web3 applications.

“I think middleware is one of the biggest present-day opportunities to drive mainstream [blockchain] development and adoption,” Steindorff told CoinDesk.

Indeed, BlockCypher CEO Catheryne Nicholson told CoinDesk that “running ethereum infrastructure is really painful.” Yet her company has thousands of customers, ranging from rogue developer teams to enterprises, paying for such ethereum API access.

With more companies providing affordable support services across the ecosystem, Hines said, startups can avoid that hassle and focus on their core competency. He added that Terminal is currently raising a Series A, with aims to eventually offer self-hosted versions of the platform for developers who prefer not to rely on centralized websites.

“Most developers need redundancy,” BlockCypher’s Nicholson said, referring to how teams need backups in case one ethereum API provider has a hiccup. “It’s not one company eat all. You need multiple players to make that ecosystem work.”

Disclosure: CoinDesk is a subsidiary of Digital Currency Group, which has an ownership stake in Terminal.

This article explains how to build a version control process for DevOps infrastructure, why Infrastructure as Code (IaC) is the foundation, and how to get started with Git and GitHub using a practical command-line walkthrough.

Why Infrastructure Needs Version Control

Infrastructure as Code (IaC) is the practice of defining servers, networks, storage, and other infrastructure resources in machine-readable configuration files rather than through manual processes or interactive consoles. IaC enables automation, testability, quality gates, and predictable deployments — the same benefits that application developers have enjoyed for years.

Storing IaC templates, shell scripts, and configuration artifacts in a version control repository brings additional benefits:

• Full audit history: Every change is recorded with a description, timestamp, and author, giving teams a clear point-in-time history from one revision to the next.
• Rollback capability: If a change breaks something, you can revert to any previous known-good state without guesswork.
• Collaboration without conflicts: Team members work from a shared central repository, merging changes in a controlled way rather than overwriting each other’s work.
• Automation triggers: Commits to a version control repository can automatically kick off pipelines — running tests, linting configuration files, or deploying to a development or staging environment.
• Shared understanding: Everyone on the team — developers, operations engineers, and security — can inspect a single source of truth for all resources that support a given application.

How Version Control Works for Infrastructure Teams

The mechanics of version control are the same whether you are tracking application code or an Ansible playbook. A central repository stores all files. Changes are tracked incrementally — each new commit layers on top of the previous state, preserving the full history. Team members synchronize a local copy of the repository, make changes, and merge those changes back to the central repository when ready.

This workflow reduces risk. Bugs introduced by a change can be isolated and reverted. Updates that break a deployment can be rolled back without affecting unrelated work. Multiple engineers can work on the same code base simultaneously, improving velocity without sacrificing consistency.

For infrastructure-focused engineers, adopting version control also means embracing software development habits: writing descriptive commit messages (e.g., “Applied security patch to base OS image referenced in Terraform module”), using branches for experimental changes, and submitting pull requests for peer review before merging to a main branch.

Choosing a Version Control System: Git and GitHub

Git is the most widely used version control system in the industry. It is distributed, meaning every engineer works with a full local copy of the repository — including its complete history — and can commit changes offline. Those commits are then pushed to a shared remote server when connectivity is available.

Git is open source, and a wide ecosystem of hosted platforms is built on top of it, including GitHub, GitLab, and Bitbucket. When selecting a platform, consider:

• Public vs. private repositories: Public repositories are visible to anyone. Infrastructure code almost always belongs in a private repository.
• Access controls: Fine-grained permissions determine who can read, write, or merge changes to protected branches.
• CI/CD integration: Most hosted Git platforms offer built-in pipelines or integrate with external tools such as Jenkins, GitHub Actions, or GitLab CI.
• Secrets management: Never store secrets, credentials, or API keys in a version control repository. Use a dedicated secrets manager and reference secrets by name in your IaC templates.

Practical Walkthrough: Git Version Control from the Command Line

The following walkthrough demonstrates the core Git version control workflow using the command line and a GitHub remote repository. The same workflow applies whether you are tracking a Terraform module, a Kubernetes manifest, or a CloudFormation template.

Step 1: Initialize a Local Repository

Open a terminal and navigate to the directory where you want to store your repositories. Create a new folder for this repository and initialize it with Git:

mkdir my-first-repo
cd my-first-repo
git init

Git responds with: Initialized empty Git repository in .../my-first-repo/.git/

Step 2: Add a File and Stage the Change

Create a README file. On GitHub, this file is rendered as the repository’s landing page:

echo "# my-first-repo" >> README.md

The file exists on disk but is not yet tracked by Git. Stage it to tell Git you want to include this change in the next commit:

git add README.md

Step 3: Commit the Change

Commit the staged change to the local repository with a descriptive message:

git commit -m "Initial commit: add README"

Write commit messages that describe why a change was made, not just what changed. For infrastructure code, this habit is especially valuable during incident investigation.

Step 4: Connect to a Remote Repository on GitHub

Sign in to GitHub and create a new private repository named my-first-repo. Then link the local repository to the remote:

git remote add origin https://github.com/[your-github-username]/my-first-repo.git

Push the local commits to the remote repository:

git push -u origin main

Other team members can now clone the repository to their own machines:

git clone https://github.com/[your-github-username]/my-first-repo.git

Step 5: Make a Change and Inspect the Diff

Edit README.md using any text editor. Add a line of text describing what the repository contains. Check which files have been modified:

git status

Stage and commit the update:

git add README.md
git commit -m "Update README with repository description"

Push the change to GitHub:

git push -u origin main

Navigate to the repository on GitHub and view the latest commit. GitHub displays a split-screen diff showing what was added (highlighted in green) and what was removed (highlighted in red) between the two versions. This visibility is one of the most practical benefits of version control for infrastructure teams: you can immediately see what changed and when.

Step 6: Extend the Repository with Infrastructure Artifacts

With the workflow in place, add the infrastructure files you need to track: Terraform modules, CloudFormation templates, Ansible playbooks, Kubernetes manifests, shell scripts, and pipeline definitions. Follow the same pattern for every change:

1. Modify or add a file.
2. Stage the change with git add.
3. Commit with a descriptive message using git commit -m.
4. Push to the remote repository with git push.

Branching Strategies for Infrastructure Code

Many teams use multiple branches to manage infrastructure changes safely. A common pattern is:

• Main branch: Represents the production-ready state of all infrastructure. Direct commits are typically blocked; changes arrive via pull requests.
• Feature branches: Short-lived branches where engineers develop and test a specific change — for example, adding a new VPC configuration or updating an AMI reference.
• Environment branches: Some teams maintain separate branches for development, staging, and production environments, promoting changes upward through the chain after validation.

Pull requests serve as the gatekeeping mechanism. Before a change merges to the main branch, other engineers can review the diff, leave comments, and require that automated tests pass. This process catches errors in infrastructure code before they reach production.

Connecting Version Control to Automation

Version control becomes even more powerful when it triggers automation. A commit or a merge to a protected branch can automatically:

• Run linting and static analysis on infrastructure templates (e.g., terraform validate, cfn-lint, or ansible-lint).
• Execute integration tests against a temporary environment.
• Deploy the updated infrastructure to a development or staging environment.
• Notify the team of the outcome via a chat integration or email.

This automation loop is the foundation of a mature DevOps pipeline. The version control repository becomes the single trigger point for all downstream activity, eliminating manual handoffs and reducing the opportunity for human error.

IaC Tooling That Works Well with Version Control

Version control is tool-agnostic, but the following categories of IaC tooling are commonly stored in Git repositories:

• Provisioning tools: Terraform, AWS CloudFormation, Azure Resource Manager templates, Google Cloud Deployment Manager, and OpenStack Heat define the infrastructure resources themselves.
• Configuration management: Ansible, Chef, and Puppet manage the software and settings installed on provisioned servers. These artifacts complement IaC provisioning templates and belong in the same repository or a linked one.
• Container and orchestration manifests: Kubernetes YAML files, Helm charts, and Docker Compose files define how applications run on the infrastructure.

Public and private cloud platforms — including AWS, Microsoft Azure, and Google Cloud Platform — provide APIs that these tools use to provision resources consistently and repeatedly. With cloud APIs and IaC templates version-controlled in Git, infrastructure deployments become as repeatable and auditable as application deployments.

Summary

Building a version control process for DevOps infrastructure is not complicated, but it does require a deliberate shift in how infrastructure teams work. The steps are straightforward: adopt Infrastructure as Code, store all artifacts in Git, follow a consistent commit-and-push workflow, use branches and pull requests to gate changes, and wire the repository to an automated pipeline.

The result is infrastructure that is auditable, reversible, collaborative, and automated — the same properties that software development teams have relied on for decades, now applied to the systems that run your applications.

The Culture-Shock Problem With DevOps Adoption

For IT leaders trying to move their organizations from traditional, waterfall-style development to a DevOps model, the biggest threat isn’t tooling — it’s culture shock. Forcing an entire organization to change how it thinks about delivery, ownership, and feedback all at once is a recipe for disruption, resistance, and rollback.

One proven strategy for navigating this transition is to establish a DevOps Center of Excellence (CoE): a dedicated, protected team or environment where DevOps practices can start small, demonstrate value, and gradually expand across the organization. Rather than asking everyone to change at once, the CoE creates a beachhead from which the new approach can grow organically.

“Your business needs to run day-to-day into the future, so you have to find a separate area where you can create things in new ways,” says Kevin Baril. “An innovation hub, center of excellence, tiger team — whatever you want to call it. Create an environment where you can break from the traditional waterfall approach and leverage agile capabilities.”

Here are four concrete steps Baril recommends for building a successful DevOps Center of Excellence.

Step 1: Choose the Right Use Cases

The DevOps CoE will succeed or fail based on which business functions it targets first. Picking the wrong use case — one that is too complex, too politically sensitive, or too tightly coupled with legacy systems — can doom the initiative before it gains momentum.

Baril frames this as a leadership alignment problem first. “This is part of the transformational leadership concept. You have to have a leader who’s done a good job of aligning corporate business strategy with IT strategy and the architecture you’re using to enable it.”

When that alignment exists, it becomes much clearer which capabilities need to be commodity and cost-efficient versus which need to be differentiated and highly responsive to change. Target the latter category for your first DevOps initiatives — those are the areas where faster iteration and tighter feedback loops deliver the most measurable value.

Take your time here. As Baril puts it: “It takes a while to build that understanding of which use case should be first.” Rushing into the wrong domain wastes the goodwill and momentum that a successful early project would otherwise generate.

Step 2: Learn the Business Process Deeply Before You Build

Once you’ve identified your first use case, resist the urge to jump straight into toolchain setup or sprint planning. The CoE team needs to develop a thorough understanding of the business process they are improving before they can improve it effectively.

“Have a clear understanding of the outcome you’re trying to achieve and organize your team to accomplish that,” Baril says. “Your core team, introducing this new, transformative concept, needs to be fluent in the business on those concepts. Because using agility to create improvement depends a lot on the process you’re trying to improve.”

This means defining success criteria up front — whether the goal is faster release cycles, reduced manual effort, improved uptime, or lower infrastructure cost — and ensuring the entire team understands what “done” looks like. Without this clarity, velocity alone is not a useful measure of progress.

Step 3: Expect and Encourage Deep Business Involvement

One of the most important — and often underestimated — aspects of building a DevOps CoE is involving business stakeholders as active participants, not passive observers or end-users.

Baril points out that the frustration with waterfall development is shared equally between IT and the business. “Over the last 10 to 20 years, requirements were gathered in a structured way and by the time you built the system, a lot of the requirements had changed.” Business leaders often end up with technology that no longer matches what they actually need — a problem DevOps practices, with their emphasis on continuous feedback and iteration, are specifically designed to address.

Crucially, the boundary between IT and business functions has been blurring for years. “Increasingly, effective IT leaders and effective members of IT departments have a solid understanding of the business application of whatever they’re looking to accomplish,” Baril notes.

This cuts both ways. Modern low-code and platform-oriented tooling means that technically capable people in business departments can now play a direct role in building and deploying solutions. “So digital natives may be working with the rollout of new applications, and it wouldn’t be strange to have those people come from a business area instead of IT.” Your CoE should actively recruit from both sides of that fence.

Step 4: Don’t Assume You Need a Large Team to Start

Talent acquisition is often cited as the most challenging barrier to standing up a DevOps CoE. The skill set required — spanning development, operations, security, and business domain knowledge — is genuinely hard to find in one place. But that doesn’t mean you need a large team from day one.

Some organizations free up existing IT staff by automating routine tasks or consolidating systems, redirecting that capacity toward the CoE. This is a slower route but has the advantage of preserving institutional knowledge. The faster approach is targeted hiring.

“In many companies, it’s affordable to do that,” Baril says. “You have turnover, and the CIO has wide discretion about hiring. If you make the decision that this is a priority for us, then you can bring on a core group of people with the mindset to create a DevOps center of excellence.”

The key word here is mindset. The CoE team doesn’t need to be large — it needs to be composed of people who are genuinely committed to iterative improvement, cross-functional collaboration, and shared ownership of outcomes. A small, motivated team with the right culture will outperform a larger group that is simply executing instructions.

Key Takeaways

• Start with a protected space. A CoE lets DevOps practices prove their value without disrupting the rest of the organization.
• Use case selection is a strategic decision, not a technical one. Align it with business strategy before picking tools or hiring staff.
• Business fluency is non-negotiable. The CoE team must understand the processes they are modernizing, not just the technology they are deploying.
• Business stakeholders are partners, not customers. Involve them early and often; they have as much to gain from DevOps as IT does.
• Team size matters less than team mindset. A small, aligned group with the right culture can bootstrap a CoE effectively.

Building a DevOps Center of Excellence is ultimately an exercise in change management as much as it is an engineering challenge. Getting the organizational design right from the start gives the initiative the best chance of scaling across the rest of the enterprise over time.

The Problem: Slow Rebuilds in Docker Compose

If you are new to Docker Compose and working on a Go project, you may have noticed that every time you change a source file, the feedback loop feels painfully slow. The naive workflow looks like this:

docker-compose build
docker-compose up

The issue is that docker-compose build rebuilds the entire image from scratch—including re-downloading and re-compiling all Go dependencies—even when only one source file changed. On a project with many dependencies this can take minutes per iteration.

Why the Volume Mount Approach Breaks

A natural instinct is to skip the full image rebuild by running a build command directly against a running container:

docker-compose run web go build .
docker-compose run web ./app

or

docker-compose run web go build .
docker-compose restart

This seems reasonable because a host-to-container volume mount means the container already has access to updated source files—there is no need to copy them in again. However, two problems occur:

• The new binary is not picked up. docker-compose restart restarts the service using the command defined in docker-compose.yml, but the running process image is already in memory. The container does not re-exec the binary after restart in the way you might expect.
• Port forwarding breaks. docker-compose run starts a brand-new, one-off container. It does not reuse the port bindings of the up-managed container, so the published port is no longer mapped correctly.

Reference Configuration

Here is the Dockerfile and Compose file that illustrate the typical starting point for this problem:

Dockerfile

FROM golang:1.8

COPY . /go/src/github.com/codeblooded/test1
WORKDIR /go/src/github.com/codeblooded/test1

RUN echo $PATH
RUN go get -d -v ./...
RUN go install -v ./...

RUN go build -o test1 .
CMD ["test1"]
EXPOSE 3470

docker-compose.yml

version: '3'
services:
  postgres:
    image: postgres
    volumes:
      - ./db/data/psql:/var/lib/postgresql/data
      - ./db/schema:/db/schema
  redis:
    image: redis
    volumes:
      - ./db/data/redis:/data
  server:
    build: .
    command: test1
    volumes:
      - .:/go/src/github.com/codeblooded/test1
    ports:
      - "3470:3470"
    depends_on:
      - postgres
      - redis

Root Cause: The Image Layer Cache Is Not Being Used Properly

The Dockerfile above copies the entire project directory before running go get. This means Docker cannot cache the dependency-download layer separately from the source code. Every time a source file changes, Docker invalidates the COPY . . layer, which forces every subsequent layer—including go get—to re-run.

Solution 1: Fix the Layer Cache Order

If you are using Go modules (go.mod / go.sum), copy only those files first, run go mod download, and then copy the rest of the source. Docker caches each layer independently, so the dependency download layer is only invalidated when go.mod or go.sum changes—not on every source edit.

FROM golang:1.21

WORKDIR /app

# Cache dependencies separately from source code
COPY go.mod go.sum ./
RUN go mod download

# Now copy the rest of the source
COPY . .

RUN go build -o server .
CMD ["./server"]
EXPOSE 3470

With this structure, docker-compose build only re-downloads dependencies when the module files change. Rebuilding after a source-only edit becomes much faster.

Solution 2: Use exec + Stop/Start Instead of restart

If you want to rebuild inside the running container without a full image rebuild, use docker-compose exec (not run) to compile inside the already-running service container, then stop and start the service:

# Compile inside the existing container
docker-compose exec server go build -o /app/server .

# Stop and start (not restart) so CMD is re-executed
docker-compose stop server
docker-compose start server

docker-compose exec runs the command inside the container that is already listening on the correct port, so port forwarding remains intact. stop + start (rather than restart) ensures the entry-point binary is re-executed from disk.

Note: the container’s CMD must point to the binary at a predictable path that the new build overwrites.

Solution 3: Use a Live-Reload Tool

For the fastest inner-loop experience during development, use a file-watching live-reload tool as the container’s entrypoint. The tool watches your source files via the shared volume and automatically recompiles and restarts the Go binary when files change—no manual rebuild step needed.

Popular options for Go include:

• Air (github.com/air-verse/air) — a widely used live-reload tool for Go applications.
• CompileDaemon (github.com/githubnemo/CompileDaemon) — watches Go files and triggers go build on change.
• Reflex (github.com/cespare/reflex) — a general-purpose file watcher that can run any command.

A Dockerfile using Air for development might look like this:

FROM golang:1.21

WORKDIR /app

# Install Air
RUN go install github.com/air-verse/air@latest

COPY go.mod go.sum ./
RUN go mod download

COPY . .

EXPOSE 3470
CMD ["air"]

With the host source directory mounted as a volume (.:/app), Air detects file changes on the host, rebuilds the binary inside the container, and restarts it—all automatically. Port bindings remain stable because the container itself never stops.

Choosing the Right Approach

Key Takeaways

• Never run docker-compose build on every source change if you can avoid it. Fix your Dockerfile layer order so that dependencies are cached separately from application code.
• Use docker-compose exec (not run) when you need to run a command inside an already-running service container. run creates a new container with different port bindings.
• For active Go development inside Docker Compose, a live-reload tool like Air gives you the fastest and most ergonomic feedback loop with minimal configuration.
• Volume mounts alone do not cause the container to pick up a new binary—you still need to stop and restart the process, or use a watcher that does this automatically.