Category: Engineering Leadership

Starling Bank’s Penalty: How to Strengthen Your Compliance Efforts

Starling Bank’s Penalty: How to Strengthen Your Compliance Efforts

By | | Comments 1 comment

Introduction

The rapid growth of the fintech industry has brought with it immense opportunities for innovation, but also significant risks in terms of regulatory compliance and real security. Starling Bank, one of the UK’s prominent digital banks, recently faced a £29 million fine in October 2024 from the Financial Conduct Authority (FCA) for serious lapses in its anti-money laundering (AML) and sanctions screening processes. This fine is part of a broader trend of fintechs grappling with regulatory pressures as they scale quickly. Failures in compliance not only lead to financial penalties but also damage to reputation and customer trust. In most cases, it also leads to revenue loss and or a significant business impact.

In this article, we explore what went wrong at Starling Bank, examine similar compliance issues faced by other major financial institutions like Paytm, Monzo, HDFC, Axis Bank & RobinHood and propose practical solutions to help fintech companies strengthen their compliance frameworks. This also helps to establish the point that these cybersecurity and compliance control lapses are not restricted to geography and are prevalent in the US, UK, India and many other regions. Additionally, we dive into how vulnerabilities manifest in growing fintechs and the increasing importance of adopting zero-trust architectures and AI-powered AML systems to safeguard against financial crime.

Background

In October 2024, Starling Bank was fined £29 million by the Financial Conduct Authority (FCA) for significant lapses in its anti-money laundering (AML) controls and sanctions screening. The penalty highlights the increasing pressure on fintech firms to build robust compliance frameworks that evolve with their rapid growth. Starling’s case, although high-profile, is just one in a series of incidents where compliance failures have attracted regulatory action. This article will explore what went wrong at Starling, examine similar compliance failures across the global fintech landscape, and provide recommendations on how fintechs can enhance their security and compliance controls.

What Went Wrong and How the Vulnerability Manifested

The FCA investigation into Starling Bank uncovered two major compliance gaps between 2019 and 2023, which exposed the bank to financial crime risks:

  1. Failure to Onboard and Monitor High-Risk Clients: Starling’s systems for onboarding new clients, particularly high-risk individuals, were not sufficiently rigorous. The bank’s AML mechanisms did not scale in line with the rapid increase in customers, leaving gaps where sanctioned or suspicious individuals could go undetected. Despite the bank’s growth, the compliance framework remained stagnant, resulting in breaches of Principle 3 of the FCA’s regulations for businesses​(Crowdfund Insider)​(FinTech Futures).
  2. Inadequate Sanctions Screening: Starling’s sanctions screening systems failed to adequately identify transactions from sanctioned entities, a critical vulnerability that persisted for several years. With insufficient real-time monitoring capabilities, the bank did not screen many transactions against the latest sanctions lists, leaving it exposed to potentially illegal activity​(FinTech Futures). This is especially concerning in a financial ecosystem where transactions are frequent and high in volume, requiring robust systems to ensure compliance at all times.

These vulnerabilities manifested in Starling’s inability to effectively prevent financial crime, culminating in the FCA’s action in October 2024.

Learning from Similar Failures in the Fintech Industry

  1. Paytm’s Cybersecurity Breach Reporting Delays (October 2024): In India, Paytm was fined for failing to report cybersecurity breaches in a timely manner to the Reserve Bank of India (RBI). This non-compliance exposed vulnerabilities in Paytm’s internal governance structures, particularly in their failure to adapt to rapid business expansion and manage cybersecurity threats​(Reuters).
  2. HDFC and Axis Banks’ Regulatory Breaches (September 2024): The RBI fined HDFC Bank and Axis Bank in September 2024 for failing to comply with regulatory guidelines, emphasizing how traditional banks, like fintechs, can face compliance challenges as they scale. The fines were related to lapses in governance and risk management frameworks​(Economic Times).
  3. Monzo’s PIN Security Breach (2023): In 2023, UK-based challenger bank Monzo experienced a breach where customer PINs were accidentally exposed due to an internal vulnerability. Although Monzo responded swiftly to mitigate the damage, the breach illustrated the need for fintechs to prioritize backend security and implement zero-trust security architectures that can prevent such incidents​(Wired).
  4. LockBit Ransomware Attack (2024): The LockBit ransomware attack on a major financial institution in 2024 demonstrated the growing cyber threats that fintechs face. This attack exposed the weaknesses in traditional cybersecurity models, underscoring the necessity of adopting zero-trust architectures for fintech companies to protect sensitive data and transactions from malicious actors​(NCSC).
  5. Robinhood’s Regulatory Scrutiny (2021-2022): In June 2021, Robinhood was fined $70 million by FINRA for misleading customers, causing harm through platform outages, and failing to manage operational risks during the GameStop trading frenzy. Robinhood’s systems were not equipped to handle the surge in trading volumes, leading to severe service disruptions and a failure to communicate risks to customers.
  6. Robinhood Crypto’s Cybersecurity Failure (2022): In August 2003, Robinhood was fined $30 million by the New York State Department of Financial Services (NYDFS) for failing to comply with anti-money laundering (AML) regulations and cybersecurity obligations related to its cryptocurrency trading operations. The fine was issued due to inadequate staffing, compliance failures, and improper handling of regulatory oversight within its crypto business. Much like Starling, Robinhood’s compliance systems lagged behind its rapid business growth​ (Compliance Week)

Key Statistics in the Fintech Compliance Landscape

  • 65% of organizations in the financial sector had more than 500 sensitive files open to every employee in 2023, making them highly vulnerable to insider threats​.
  • The average cost of a data breach in financial services was $5.85 million in 2023, a significant figure that shows the financial impact of security vulnerabilities​.
  • 27% of ransomware attacks targeted financial institutions in 2022, with the number of attacks continuing to rise in 2024, further highlighting the importance of robust cybersecurity frameworks​.
  • 81% of financial institutions reported a rise in phishing and social engineering attacks in 2023, emphasizing the need for employee awareness and strong access controls​.
  • By 2025, the global cost of cybercrime is projected to exceed $10.5 trillion annually, a figure that will disproportionately impact fintech companies that fail to implement strong security protocols​.

Recommendations for Strengthening Compliance and Security Controls

To prevent future compliance breaches, fintech firms should prioritise scalable, technology-enabled compliance solutions. This requires empowering Compliance Heads, Information Security Teams, CISOs, and CTOs with the necessary budgets and authority to develop secure-by-design environments, teams, infrastructure, and products.

  1. AI-Powered AML Systems: Leverage artificial intelligence (AI) and machine learning to enhance AML systems. These technologies can dynamically adjust to new threats and process high volumes of transactions to detect suspicious patterns in real time. This approach will ensure that fintechs can comply with evolving regulatory requirements while scaling.
  2. Zero-Trust Security Models: As the LockBit ransomware attack showed in 2024, fintechs must adopt zero-trust architectures, where every user and device interacting with the system is continuously authenticated and verified. This reduces the risk of internal breaches and external attacks​(Cloudflare).
  3. Real-Time Auditing and Blockchain for Transparency: Real-time auditing, combined with blockchain technology, provides an immutable and transparent record of all financial transactions. This would help fintechs like Starling avoid the pitfalls of delayed sanctions screening, as blockchain ensures immediate and traceable compliance checks​(EY).
  4. Multi-Layered Sanctions Screening: Implement a multi-layered sanctions screening system that combines automated transaction monitoring with manual oversight for high-risk accounts. This dual approach ensures that fintechs can monitor suspicious activities while maintaining compliance with global regulatory frameworks​(Exiger)​(FinTech Futures).
  5. Continuous Employee Training and Governance: Strong governance structures and regular compliance training for employees will ensure that fintechs remain agile and responsive to regulatory changes. This prepares the organization to adapt as new regulations emerge and customer bases expand.

Conclusion

The £29 million fine imposed on Starling Bank in October 2024 serves as a crucial reminder for fintech companies to integrate robust compliance and security frameworks as they grow. In an industry where regulatory scrutiny is intensifying, the fintech players that prioritize compliance will not only avoid costly fines but also position themselves as trusted institutions in the financial services world.

Further Reading and References

  1. RBI Fines HDFC, Axis Bank for Non-Compliance with Regulations (September 2024)
  2. RBI Fines Paytm for Not Reporting Cybersecurity Breaches on Time (October 2024)
  3. LockBit’s Latest Attack Shows Why Fintech Needs More Zero Trust (2024)
  4. Monzo PIN Security Breach Explained (2023)
  5. Varonis Cybersecurity Statistics (2023)

Scholarly Papers & References

  1. Barr, M.S.; Jackson, H.E.; Tahyar, M. Financial Regulation: Law and Policy. SSRN Scholarly Paper No. 3576506, 2020. Available online: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3576506
  2. Suryono, R.R.; Budi, I.; Purwandari, B. Challenges and Trends of Financial Technology (Fintech): A Systematic Literature Review. Information 2020, 11, 590. https://doi.org/10.3390/info11120590
  3. AlBenJasim, S., Dargahi, T., Takruri, H., & Al-Zaidi, R. (2023). FinTech Cybersecurity Challenges and Regulations: Bahrain Case Study. Journal of Computer Information Systems, 1–17. https://doi.org/10.1080/08874417.2023.2251455

By learning from past failures and adopting stronger controls, fintechs can mitigate the risks of financial crime, protect customer data, and ensure compliance in an increasingly regulated industry.

Why Did Elastic Decide to Go Open Source Again?

Why Did Elastic Decide to Go Open Source Again?

By | | Comments 0 Comment

Elastic’s Return to Open Source: The Knight is back to the Pavilion

Elastic, the company behind Elasticsearch, recently decided to revert to an open-source licensing model after four years of operating under a proprietary license. This decision reflects a shift in strategy that emphasizes community-driven innovation and collaboration. In 2019, Elastic initially adopted a proprietary model to protect its intellectual property from cloud providers like Amazon Web Services (AWS), which were benefiting from Elasticsearch without contributing to its development. However, the move away from open-source posed its own challenges, including alienating the developer community that had helped build Elasticsearch into a widely-used tool.

In 2024, Elastic CEO Shay Banon announced the company’s return to an open-source framework. He explained that this decision stems from the belief that open collaboration fosters innovation and better serves the long-term interests of both the company and its user base. “We believe that the best products are built together,” Banon stated, emphasizing the value of community engagement in product development.

Recent Changes in Open-Source Licensing Models

Elastic’s decision is not an isolated incident. Over the past few years, several other technology companies have reconsidered their licensing models in response to the changing dynamics of software development and cloud service providers. These companies have struggled with how to balance open-source principles with the need to protect their commercial interests.

  1. Redis Labs
    Redis Labs initially licensed Redis under a permissive open-source license, but in 2018, the company adopted the Commons Clause to prevent cloud providers from offering Redis as a service without contributing to its development. However, after facing backlash from the developer community, Redis Labs adjusted its approach by introducing Redis Stack under more community-friendly terms, highlighting the difficulty of maintaining open-source integrity while ensuring business protection.
  2. HashiCorp
    In 2023, HashiCorp, known for popular tools like Terraform, adopted a Business Source License (BSL), which restricts the usage of its software in certain commercial contexts. HashiCorp’s move was driven by concerns over cloud providers monetizing its tools without contributing back to the open-source community. While BSL is not a traditional open-source license, HashiCorp continues to maintain a balance between openness and protecting its intellectual property, showing how companies are navigating complex market dynamics.
  3. MongoDB
    MongoDB’s shift to the Server Side Public License (SSPL) in 2018 was another major development in the open-source licensing debate. The SSPL aims to prevent cloud service providers from exploiting MongoDB’s open-source code without contributing back. While the SSPL is more restrictive than traditional open-source licenses, MongoDB’s goal was to retain the open-source ethos while ensuring that cloud vendors could not commercialize the software without contributing to its development.
  4. Chef Software
    Chef, an automation tool provider, switched all of its products to open-source in 2019 after years of operating under a mixed licensing model. This shift was largely a response to the growing demand for transparency and community collaboration. Chef’s decision allowed it to rebuild trust within its user base and align its business strategy with the broader trends in software development.

Impact on the Average Software Developer

For the average software developer, these licensing model changes can profoundly impact their work, career growth, and day-to-day development practices.

  1. Access to Cutting-Edge Tools
    When companies like Elastic and MongoDB return to open-source models, developers gain unrestricted access to powerful tools and frameworks. This democratizes the technology, allowing developers from small companies, startups, and even personal projects to leverage the same tools that major enterprises use, without the barrier of expensive proprietary licenses. For many developers, open-source provides not just tools, but an entire ecosystem for experimentation, learning, and rapid prototyping.
  2. Contributing to Open-Source Communities
    Open-source contributions are an essential career-building tool for many developers. By contributing to open-source projects, developers can gain real-world experience, build portfolios, and even influence the direction of widely-used technologies. When companies like HashiCorp and Redis Labs shift their focus back to open-source, it increases opportunities for developers to become part of a larger, global development community.
  3. Career and Learning Opportunities
    Exposure to open-source projects allows developers to work with cutting-edge technology and methodologies. This can accelerate learning, as open-source projects are often evolving quickly with input from diverse and global teams. Additionally, contributing to popular open-source projects like Elastic or Kubernetes can greatly enhance a developer’s resume and open doors to career opportunities, including job offers and consulting roles.
  4. Navigating Licensing Restrictions
    Developers must also become more adept at navigating the complexities of new licenses like SSPL and BSL. These licenses place restrictions on how open-source software can be used, especially in cloud environments. Understanding the fine print is crucial for developers working in enterprise environments or launching their own SaaS products, as improper use of open-source software can lead to legal complications. This makes legal and compliance knowledge increasingly important in modern software development roles.

Open Source vs. Open Governance: A Crucial Distinction

Elastic’s journey highlights a key debate in the software development world: the difference between open source and open governance. While many companies have embraced open-source models, few have transitioned to open governance frameworks, which involve community-driven decision-making for the project’s future direction.

As highlighted in my previous article, “Open Source vs. Open Governance: The State and Future of the Movement,” the distinction lies in control. In open-source projects, the code is freely available, but decisions regarding the project’s roadmap and key developments may still be controlled by a single entity, such as a company. In contrast, open governance ensures that decision-making is decentralized, often involving multiple stakeholders, including developers, users, and companies that contribute to the project.

For Elastic and others, returning to open-source doesn’t necessarily mean embracing open governance. Although Elastic’s code will be open for contributions, the strategic direction will still be managed by the company. This is a common approach in many high-profile open-source projects. For example, Google’s Kubernetes operates under the open-source model but is governed by a diverse group of stakeholders, ensuring the project’s direction isn’t controlled by a single entity. On the other hand, projects like OpenStack follow a more open governance approach, with broader community involvement in decision-making.

Understanding the difference between open-source and open governance is critical as the software industry evolves. Companies are beginning to realize that open-source alone doesn’t always translate into the collaborative, community-driven development they seek. Open governance provides a framework for more inclusive decision-making, but it also presents challenges in terms of efficiency and control.

Looking Ahead: Open Source as a Business Strategy

The return of Elastic and other companies to more open models indicates a growing recognition of the importance of open-source in the software industry. For Elastic, this decision is about more than just licensing; it’s about reconnecting with a developer community that thrives on transparency and collaboration. By embracing open-source again, Elastic hopes to accelerate product development and foster stronger relationships with users.

This broader trend shows that while companies are still cautious about cloud providers exploiting their software, they are increasingly finding ways to leverage open-source models as a business strategy. These recent changes to licensing frameworks highlight the evolving nature of software development and the role open-source plays in it.

For organizations navigating the complex decision between proprietary and open-source models, the key lesson from Elastic’s experience is that the long-term benefits of community-driven development and innovation can outweigh the short-term protection of proprietary models. As more companies follow suit, it’s clear that open-source is not just a technical choice—it’s a business strategy.

Further Reading:

  1. Why Open Source Matters for Innovation – Alan Turing Institute
  2. The Future of Open Source: What to Expect in 2024 and Beyond – MIT Technology Review
  3. Why Every Company Should be Open-Source Aligned – Forbes

References:

Key Reasons Founding CTOs Move Sideways in Tech Startups

Key Reasons Founding CTOs Move Sideways in Tech Startups

By | | Comments 0 Comment

In the world of startups, it’s not uncommon to hear about founding CTOs being ousted or sidelined within a few years of the company’s inception. For many, this seems paradoxical—after all, these are often individuals who are not only experts in their fields but also the technical visionaries who brought the company to life. Yet, within 3–5 years, many of them find themselves either pushed out of their executive roles or relegated to a more visionary or peripheral position in the organization.

But why does this happen?

The Curious Case of the Founding CTO

About 6-7 years back, while assisting a couple of VC firms in performing technical due diligence with their investments, I noticed a pattern: founding CTOs who had built groundbreaking technology and secured millions in funding were being removed from their positions. These were not just “any” technologists—they were often world-class experts, with pedigrees from prestigious institutions like Cambridge, Stanford, Oxford, MIT, IIT(Israel) and IIT (India). Their technical competence was beyond question, so what was causing this rapid turnover?

The Business Acumen Gap

After numerous conversations with both the displaced CTOs and the investors who backed their companies, a common theme emerged: there was a significant gap in business acumen between the CTOs and the boards of directors. As the companies grew, this gap widened, eventually becoming a chasm too large to bridge.

The Perception of Arrogance

One of the most frequently cited issues was the perception of arrogance. Many founding CTOs, steeped in deep technical knowledge, would often express disdain or impatience towards board members and executive leadership team (ELT) members who lacked a technical background. This disdain often manifested in meetings, where CTOs would engage in “geek speak,” using highly technical language that alienated non-technical stakeholders. This attitude can make the board feel undervalued and disconnected from the technology’s impact on the business, leading to friction between the CTO and other executives.

Failure to Translate Technology into Business Outcomes

Another critical issue was the inability—or unwillingness—to translate technical initiatives into tangible business outcomes. CTOs would present technology roadmaps without tying them to the company’s broader business objectives; and in extreme cases, even product roadmaps! This disconnect led to frustration among board members who wanted to understand how technology investments would drive revenue, reduce costs, or create competitive advantages. According to an article in Harvard Business Review, this lack of alignment between technical leadership and business strategy often results in a loss of confidence from investors & executive leadership who see the CTO as out of sync with the company’s growth trajectory.

Lack of Proactive Communication and Risk Management

Founding CTOs were also often criticized for failing to communicate proactively. When projects fell behind schedule or technical challenges arose, many CTOs would either remain silent or offer vague assurances such as, “You have to trust me.” Sometimes, they fail to communicate the underlying problems causing this. This lack of transparency and the absence of a clear, proactive plan to mitigate risks eroded the board’s confidence in their leadership. As noted by TechCrunch, this lack of foresight and communication can lead to the CTO being perceived as “dead weight” on the cap table, ultimately leading to their removal or sidelining.

The Statistics Behind the Trend

Research supports the observation that founding CTOs often struggle to maintain their roles as companies scale. According to a study by Harvard Business Review, more than 50% of founding CTOs in high-growth startups are replaced within the first 5 years. The reasons cited align with the issues mentioned above—poor communication, lack of business alignment, and a failure to scale leadership skills as the company grows.

Additionally, a survey by the Startup Leadership Journal revealed that 70% of venture capitalists have replaced a founding CTO at least once in their careers. This statistic underscores the importance of not only possessing technical expertise but also developing the necessary business acumen to maintain a leadership role in a rapidly growing company.

Real-World Examples: CTOs Who Fell from Grace

Several high-profile cases illustrate this trend. For instance, at Uber, founding CTO Oscar Salazar eventually took a step back from his leadership role as the company’s growth demanded a different set of skills. Similarly, at Twitter, co-founder and CTO Noah Glass was famously sidelined during the company’s early years, despite his pivotal role in its creation.

In another notable case, at Zenefits, founding CTO Laks Srini was moved to a less central role as the company faced regulatory challenges and rapid growth. The decision to shift his role was driven by the need for a leadership team that could navigate the complexities of a scaling business.

And, the list is too long, so I am adding about 8 names which is bound to elicit a reaction.

NameCompanyFired/Left on YearMost Likely Reason
Scott ForstallApple2012Abrasive management style and failure of Apple Maps
Kevin LynchAdobe2013Contention over Flash technology, departure to join Apple
Tony FadellApple2008Internal conflicts over strategic directions
Amit SinghalGoogle/Uber2017Dismissed from Uber due to harassment allegations
Balaji SrinivasanCoinbase2019Strategic shifts away from decentralization
Alex StamosFacebook2018Disagreements over handling misinformation and security issues
Michael AbbottTwitter2011Executive reshuffle during strategic redirection
Shiva RajaramanWeWork2018Departure during company instability and failed IPO

The Path Forward for Aspiring CTOs

For current and aspiring CTOs, the lessons are clear: technical expertise is essential, but it must be complemented by strong business acumen, communication skills, and a proactive approach to leadership. As a company scales, so too must the CTO’s ability to align technology with business objectives, communicate effectively with non-technical stakeholders, and manage both risks and expectations.

CTOs who can bridge the gap between technology and business are far more likely to maintain their executive roles and continue to drive their companies forward. For those who fail to adapt, the fate of being sidelined or replaced is an all-too-common outcome.

Conclusion

The role of the CTO is critical, especially in the early stages of a startup. However, as the company grows, the demands on the CTO evolve. Those who can develop the necessary business acumen, communicate effectively with a diverse range of stakeholders, and maintain a strategic focus will thrive. For others, the writing may be on the wall well before the 3–5 year mark.

What other reasons have you found that got the founding CTO fired? Share your thoughts in the comments.

References: & Further Reading

Tech Founder to CTO: The Hidden Challenges of Managing Growth in Startups

Tech Founder to CTO: The Hidden Challenges of Managing Growth in Startups

By | | Comments 0 Comment

The role of the Chief Technology Officer (CTO) in a startup is dynamic and challenging, particularly for first-time technical cofounders. While the early stages of a startup demand intense technical involvement and innovation, the role evolves significantly as the company grows. This evolution often highlights stark differences in the required skill sets at different stages, posing challenges for first-time technical cofounders but offering opportunities for serial entrepreneurs.

The Initial Phase: Technical Mastery and Hands-On Development

In a startup’s early days, the technical cofounder, often assuming the CTO role, is deeply immersed in product development’s intricacies. This period is characterized by rapid prototyping, extensive coding, and constant iteration based on user feedback. The technical cofounder’s primary focus is to bring the product vision to life, often working with limited resources and under significant time pressure. This phase requires not just technical expertise but also a high degree of creativity and problem-solving prowess.

The Transition: From Builder to Leader

As the startup scales, the CTO’s demands change dramatically. The focus shifts from hands-on development to strategic leadership. This transition involves managing larger teams, setting long-term technical directions, and ensuring that the technology strategy aligns with the overall business goals. First-time technical cofounders often find this shift challenging because it demands skills they may not have developed. The ability to code and build is no longer enough; the role now requires people management, strategic planning, and the capacity to handle complex organizational dynamics.

The Skill Set Gap

For first-time technical cofounders, this transition can be particularly daunting. Their expertise lies in building and innovating, but scaling a technology team and managing a growing organization are entirely different challenges. These new responsibilities require experience in leadership, communication, and strategic thinking—areas where first-time founders might lack experience. The result is a skill set gap that can lead to frustration and inefficiency, both for the individual and the organization.

Serial Entrepreneurs: Experience Matters

In contrast, serial entrepreneurs often handle this transition more effectively. Having navigated the startup journey multiple times, they possess a broader range of skills and experiences. They are familiar with the different phases of growth and the changing demands of the CTO role. Serial entrepreneurs are better equipped to balance hands-on technical work with strategic leadership. They have likely experienced the pitfalls and challenges of scaling a company before and have developed the necessary skills to manage them.

Learning from Experience

Serial entrepreneurs and or seasoned engineering leaders bring a wealth of knowledge from their previous ventures, allowing them to anticipate challenges and implement solutions proactively. Their past experiences help them build robust management structures, delegate effectively, and maintain strategic focus. This adaptability and foresight are crucial for a scaling startup, where the ability to pivot and adjust is often the difference between success and failure.

The Burnout Factor

Another critical difference is how first-time technical cofounders and serial entrepreneurs handle burnout. The relentless pace and high stakes of a startup can lead to significant stress and fatigue. First-time founders, driven by their passion and vision, might find it hard to step back and delegate, leading to burnout. On the other hand, serial entrepreneurs, having experienced this before, are often more adept at recognizing the signs of burnout and taking steps to mitigate it. They understand the importance of work-life balance and are better at creating a sustainable work environment for themselves and their teams.

Strategic Decisions and Stakeholder Management

As startups grow, they attract more investors and stakeholders whose interests need to be managed. Serial entrepreneurs typically have more experience dealing with investors and understanding their expectations. They are skilled at navigating the complex landscape of stakeholder management, making strategic decisions that align with the broader goals of the company while maintaining the confidence of their investors.

Conclusion: The Path Forward

For startups, recognizing the strengths and limitations of their technical cofounders is crucial. While first-time technical cofounders bring passion and technical prowess, they may struggle with the strategic and managerial aspects as the company scales. In contrast, serial entrepreneurs, with their diverse experiences and refined skills, are often better suited to handle the evolving demands of the CTO role.

Startups should consider these dynamics when planning their leadership strategies. Providing support, mentorship, and training to first-time technical cofounders can help bridge the skill set gap. Alternatively, involving experienced leaders who can complement the technical cofounder’s strengths can create a balanced leadership team capable of steering the company through its growth phases.

Ultimately, the journey from a technical cofounder to a successful CTO is complex and challenging. Recognizing the unique contributions and potential limitations of first-time technical cofounders, while leveraging the experience of serial entrepreneurs, can significantly enhance a startup’s chances of success.

The Future is Now: How Mojo🔥 is Outpacing Python at 90000X Speed

The Future is Now: How Mojo🔥 is Outpacing Python at 90000X Speed

By | | Comments 0 Comment

Calling all AI wizards and machine learning mavericks! Get ready to be blown away by Mojo, a revolutionary new programming language designed specifically to conquer the ever-evolving realm of artificial intelligence.

Just last year, Modular Inc. unveiled Mojo, and it’s already making waves. But here’s the real kicker: Mojo isn’t just another language; it’s a “hypersonic” language on a mission to leave the competition in the dust. We’re talking about a staggering 90,000 times faster than the ever-popular Python! I wanted to share a minor disclaimer there, this is not the “Official” benchmark by The Computer Language Benchmark Game or anything institutional, it is all Modular’s internal benchmarking!

That’s right, say goodbye to hours of agonizing wait times while your AI models train. With Mojo, you’ll be churning out cutting-edge algorithms at lightning speed. Imagine the possibilities! Faster development cycles, quicker iterations, and the ability to tackle even more complex AI projects – the future is wide open.

Mind-Blowing Speed and an Engaged Community

But speed isn’t the only thing Mojo boasts about. Launched in August 2023, this open-source language (open-sourced just last month, on March 29th, 2024!) has already amassed a loyal following, surpassing a whopping 17,000 stars on its GitHub repository. That’s a serious testament to the developer community’s excitement about Mojo’s potential.

The momentum continues to build. As of today, there are over 2,500 active projects on GitHub utilizing Mojo, showcasing its rapid adoption within the AI development space.

Unveiling the Magic Behind Mojo

So, what’s the secret sauce behind Mojo’s mind-blowing performance? The folks at Modular Inc. are keeping some of the details close to their chest, but we do know that Mojo is built from the ground up for AI applications. This means it leverages advancements in compiler technology and hardware acceleration, specifically targeting the types of tasks that AI developers face every day (SIMD, vectorisation, and parallelisation)

Here’s a sneak peek at some of the advantages:

  • Multi-Paradigm Muscle: Mojo is a multi-paradigm language, offering the flexibility of imperative, functional, and generic programming styles. This allows developers to choose the most efficient approach for each specific task within their AI project.
  • Seamless Python Integration: Don’t worry about throwing away your existing Python code. Mojo plays nicely with the vast Python ecosystem, allowing you to leverage existing libraries and seamlessly integrate them into your Mojo projects.
  • Expressive Syntax: If you’re familiar with Python, you’ll feel right at home with Mojo’s syntax. It builds upon the familiar Python base, making the learning curve much smoother for experienced developers.

The Future of AI Development is Here

If you’re looking to push the boundaries of AI and machine learning, then Mojo is a game-changer you can’t afford to miss. With several versions already released, including the most recent update in March 2024 (version 0.7.2), the language is constantly evolving and incorporating valuable community feedback.

Dive into the open-source community, explore the comprehensive documentation, and unleash the power of Mojo on your next groundbreaking project. The future of AI is here, and it’s moving at breakneck speed with Mojo leading the charge! Go ahead and get it here

One Trick Pony

Just be warned that Mojo is not general purpose in nature and Python will win hands down on generic computational tasks due to,

  • Libraries –
    • Python boasts an extensive ecosystem of libraries and frameworks, such as TensorFlow, NumPy, Pandas, and PyTorch, with over 137,000 libraries.
    • Mojo has a developing library ecosystem but significantly lags behind Python in this regard.
  • Compatibility and Integration –
    • Python is known for its compatibility and integration with various programming languages and third-party packages, making it flexible for projects with complex dependencies.
    • Mojo, while generally interoperable with Python, falls short in terms of integration and compatibility with other tools and languages.
  • Popularity (Availability of devs)
    • Python is a highly popular programming language with a large community of developers and data scientists.
    • Mojo, being introduced in 2023, has a much smaller community and popularity compared to Python.
    • It is just now open sourced, has limited documentation, and is targeted at developers with system programming experience.
    • According to the TIOBE Programming Community Index, a programming language popularity index, Python consistently holds the top position.
    • In contrast, Mojo is currently ranked 174th and has a long way to go.
Mastering Cyber Defense: The Impact Of AI & ML On Security Strategies

Mastering Cyber Defense: The Impact Of AI & ML On Security Strategies

By | | Comments 0 Comment

The cybersecurity landscape is a relentless battlefield. Attackers are constantly innovating, churning out new threats at an alarming rate. Traditional security solutions are struggling to keep pace. But fear not, weary defenders! Artificial Intelligence (AI) and Machine Learning (ML) are emerging as powerful weapons in our arsenal, offering the potential to revolutionize cybersecurity.

The Numbers Don’t Lie: Why AI/ML Matters

  • Security Incidents on the Rise: According to the IBM Security X-Force Threat Intelligence Index 2023 https://www.ibm.com/reports/threat-intelligence, the average organization experienced 270 data breaches in 2022, a staggering 13% increase from the previous year.
  • Alert Fatigue is Real: Security analysts are bombarded with a constant stream of alerts, often leading to “alert fatigue” and missed critical threats. A study by the Ponemon Institute found that it takes an average of 280 days to identify and contain a security breach https://www.ponemon.org/.

AI/ML to the Rescue: Current Applications

AI and ML are already making a significant impact on cybersecurity:

  • Reverse Engineering Malware with Speed: AI can disassemble and analyze malicious code at lightning speed, uncovering its functionalities and vulnerabilities much faster than traditional methods. This allows defenders to understand attacker tactics and develop effective countermeasures before widespread damage occurs.
  • Prioritizing the Vulnerability Avalanche: Legacy vulnerability scanners often generate overwhelming lists of potential weaknesses. AI can prioritize these vulnerabilities based on exploitability and potential impact, allowing security teams to focus their efforts on the most critical issues first. A study by McAfee found that organizations can reduce the time to patch critical vulnerabilities by up to 70% using AI https://www.mcafee.com/blogs/internet-security/the-what-why-and-how-of-ai-and-threat-detection/.
  • Security SIEMs Get Smarter: Security Information and Event Management (SIEM) systems ingest vast amounts of security data. AI can analyze this data in real-time, correlating events and identifying potential threats with an accuracy far exceeding human capabilities. This significantly improves threat detection accuracy and reduces the time attackers have to operate undetected within a network.

The Future of AI/ML in Cybersecurity: A Glimpse Beyond

As AI and ML technologies mature, we can expect even more transformative applications:

  • Context is King: AI can be trained to understand the context of security events, considering user behaviour, network activity, and system configurations. This will enable highly sophisticated threat detection and prevention capabilities, automatically adapting to new situations and attacker tactics.
  • Automating Security Tasks: Imagine a future where AI automates not just vulnerability scanning, but also incident response, patch management, and even threat hunting. This would free up security teams to focus on more strategic initiatives and significantly improve overall security posture.

Challenges and Considerations: No Silver Bullet

While AI/ML offers immense potential, it’s important to acknowledge the challenges:

  • Explainability and Transparency: AI models can sometimes make decisions that are difficult for humans to understand. This lack of explainability can make it challenging to trust and audit AI-powered security systems. Security teams need to ensure they understand how AI systems reach conclusions and that these conclusions are aligned with overall security goals.
  • Data Quality and Bias: The effectiveness of AI/ML models heavily relies on the quality of the data they are trained on. Biased data can lead to biased models that might miss certain threats or flag legitimate activity as malicious. Security teams need to ensure their training data is diverse and unbiased to avoid perpetuating security blind spots.

The Takeaway: Embrace the Future

Security practitioners and engineers are at the forefront of adopting and shaping AI/ML solutions. By understanding the current applications, future potential, and the associated challenges, you can ensure that AI becomes a powerful ally in your cybersecurity arsenal. Embrace AI/ML, and together we can build a more secure future!

#AI #MachineLearning #Cybersecurity #ThreatDetection #SecurityAutomation

P.S. Check out these resources to learn more:

NIST Artificial Intelligence Risk Management Framework (AI RMF 1.0): https://www.nist.gov/itl/ai-risk-management-framework) by National Institute of Standards and Technology (NIST)

The Fork in the Road: The Curveball that Redis Pitched

The Fork in the Road: The Curveball that Redis Pitched

By | | Comments 0 Comment

In a move announced on March 20th, 2024, Redis, the ubiquitous in-memory data store, sent shockwaves through the tech world with a significant shift in its licensing model. Previously boasting a permissive BSD license, Redis transitioned to a dual-license approach, combining the Redis Source Available License (RSAL) and the Server Side Public License (SSPL). This move, while strategic for Redis Labs, has created ripples of concern in the SAAS ecosystem and the open-source community at large.

The Split: From Open to Source-Available

At its core, the change restricts how users, particularly cloud providers offering managed Redis services, can leverage the software commercially. The SSPL, outlined in the March 24th press release, stipulates that any derivative work offering the “same functionality as Redis” as a service must also be open-sourced. This directly impacts companies like Amazon (ElastiCache) and DigitalOcean, forcing them to potentially alter their service models or acquire commercial licenses from Redis Labs.

A History of Licensing Shifts

This isn’t the first time Redis Labs has ruffled feathers with licensing changes. As a 2019 TechCrunch article [1] highlights, Redis Labs has a history of tweaking its open-source license, sparking similar controversies. Back then, the company argued that cloud providers were profiting from Redis without giving back to the open-source community. The new SSPL appears to be an extension of this philosophy, aiming to compel greater contribution from commercial users.

SAAS Providers in a Squeeze

For SAAS providers, the new licensing throws a wrench into established business models. Modifying core functionality to comply with the SSPL might not be feasible, and open-sourcing their entire platform could expose proprietary code. This could lead to increased costs for SAAS companies, potentially impacting end-user pricing.

Open Source Community Divided

The open-source world is also grappling with the implications. While the core Redis functionality remains open-source under RSAL, the philosophical shift towards a more restrictive model has some worried. The Linux Foundation even announced a fork, Valkey, as an alternative, backed by tech giants like Google and Oracle. This fragmentation could create confusion and slow down innovation within the open-source Redis ecosystem.

The Road Ahead: Uncertainty and Innovation

The long-term effects of Redis’s licensing change remain to be seen. It might pave the way for a new model for open-source software sustainability, where companies can balance community development with commercial viability. However, it also raises concerns about control and potential fragmentation within open-source projects.

In conclusion, Redis’s licensing shift presents a complex scenario. While it aims to secure Redis Labs’ financial future, it disrupts the SAAS landscape and creates uncertainty in the open-source world. Only time will tell if this is a necessary evolution or a roadblock to future innovation.

References & Further Reading:

Understanding The Implications Of The Data Breaches At Microsoft.

Understanding The Implications Of The Data Breaches At Microsoft.

By | | Comments 0 Comment
Note: I started this article last weekend to try and explain the attack path  “Midnight Blizzard” used and what Azure admins should do to protect themselves from a similar attack. Unfortunately, I couldn't complete/publish it in time and now there is another breach at Microsoft. (🤦🏿) Now, I had to completely redraft it and change the focus to a summary of data breaches at Microsoft and a walkthrough on the current breach. I will publish the Midnight Blizzard defence later this week.
Microsoft Data Breach

The Timeline of the Breaches

  • 20th-25th September 2023: 60k State Department Emails Stolen in Microsoft Breach
  • 12th-25th January 2024: Microsoft breached by “Nation-State Actors”
  • 11th-14th February 2024: State-backed APTs are weaponising OpenAI models 
  • 16th-19th February 2024: Microsoft admits to security issues with Azure and Exchange servers.
Date/MonthBreach TypeAffected Service/AreaSource
February 2024Zero-day vulnerabilities in Exchange serversExchange serversMicrosoft Security Response Center blog
January 2024Nation State-sponsored attack (Russia)Email accountsMicrosoft Security Response Center blog
February 2024State-backed APTs are weaponising OpenAI modelsNot directly impacting MS services
July 2023Chinese Hackers Breach U.S. Agencies Via Microsoft CloudAzureThe New York Times, Microsoft Security Response Center blog
October 2022BlueBleed Data Leak, 0.5 Million user data leakedUser Data
December 2021Lapsus$ intrusionSource code (Bing, Cortana)The Guardian, Reuters
August 2021Hafnium attacks Exchange serversExchange serversMicrosoft Security Response Center blog
March 2021SolarWinds supply chain attackVarious Microsoft products (indirectly affected)The New York Times, Reuters
January 2020Misconfigured customer support databaseCustomer data (names, email addresses)ZDNet
This is a high-level summary of breaches and successful hacks that got reported in the public domain and picked up by tier 1 publications. There are at least a dozen more in the period, some are of negligible impact, and others are less probable

Introduction:

Today, The digital landscape is a battlefield, and even tech giants like Microsoft aren’t immune to cyberattacks. Understanding recent breaches/incidents and their root causes, and effective defence strategies is crucial for Infosec/IT and DevSecOp teams navigating this ever-evolving threat landscape. This blog post dives into the security incidents affecting Microsoft, analyzes potential attack paths, and equips you with actionable defence plans to fortify your infrastructure/network.

Selected Breaches:

  • January 2024: State actors, purported to be affiliated with Russia leveraged password spraying and compromised email accounts, including those of senior leadership. This highlights the vulnerability of weak passwords and the critical need for multi-factor authentication (MFA).
  • January 2024: Zero-day vulnerabilities in Exchange servers allowed attackers to escalate privileges. This emphasizes the importance of regular patching and prompt updates to address vulnerabilities before they’re exploited.
  • December 2021: Lapsus$ group gained access to source code due to misconfigured access controls. This underscores the importance of least-privilege access and regularly reviewed security configurations.
  • Other incidents: Supply chain attacks (SolarWinds, March 2021) and data leaks (customer database, January 2020) demonstrate the diverse threats organizations face.

Attack Paths:

Understanding attacker motivations and methods is key to building effective defences. Here are common attack paths:

  • Social Engineering: Phishing emails and deceptive tactics trick users into revealing sensitive information or clicking malicious links.
  • Software Vulnerabilities: Unpatched software with known vulnerabilities offers attackers an easy entry point.
  • Weak Passwords: Simple passwords are easily cracked, granting access to accounts and systems.
  • Misconfigured Access Controls: Overly permissive access rules give attackers more power than necessary to escalate privileges and cause damage.
  • Supply Chain Attacks: Compromising a vendor or partner can grant attackers access to multiple organizations within the supply chain.

Defence Plans:

Building a robust defense requires a multi-layered approach:

  • Patch Management: Prioritize timely patching of vulnerabilities across all systems and software.
  • Strong Passwords & MFA: Implement strong password policies and enforce MFA for all accounts.
  • Access Control Management: Implement least privilege access and regularly review configurations.
  • Security Awareness Training: Educate employees on phishing, social engineering, and secure password practices.
  • Threat Detection & Response: Deploy security tools to monitor systems for suspicious activity and respond promptly to incidents.
  • Incident Response Planning: Develop and test a plan to mitigate damage, contain breaches, and recover quickly.
  • Penetration Testing: Regularly test your defenses by simulating real-world attacks to identify and fix vulnerabilities before attackers do.
  • Network Segmentation: Segment your network to limit the potential impact of a breach by restricting access to critical systems.
  • Data Backups & Disaster Recovery: Regularly back up data and have a plan to restore it in case of an attack or outage.
  • Stay Informed: Keep up-to-date on the latest security threats and vulnerabilities by subscribing to security advisories and attending industry conferences.

Conclusion:

Cybersecurity is an ongoing battle, but by understanding the tactics employed by attackers and implementing these defence strategies, IT/DevOps admins can significantly reduce the risk of breaches and protect their networks and data. Remember, vigilance and continuous improvement are key to staying ahead of the curve in the ever-evolving cybersecurity landscape.

Disclaimer: This blog post is for informational purposes only and should not be considered professional security advice. Please consult with a qualified security professional for guidance specific to your organization or mail me for an obligation free consultation call.

References and Further Reading:

Why Startups Need To Architect Cloud Agnostic Products

Why Startups Need To Architect Cloud Agnostic Products

By | | Comments 0 Comment

Nobody plans to leave AWS in the startup world, but as they say, “sh** happens.”

An image of multiple clouds over a desk

As engineers, when we write software, we’re taught to keep it elegant by never depending directly on external systems. We write wrappers for external resources, we encapsulate data and behaviour and standardise functions with libraries. 

But, When it comes to the cloud… “eerie silence”

Companies have died because they needed to move off AWS or GCP but couldn’t do it in a reasonable and cost-effective timeline.

We (at Itilite) had a close call with GCP, which served as our brush with the fire. Google had arguably one of the best Distance Matrix capabilities out there.  It was used in one of our core logic and ML models. And on one fine Monday afternoon, I have to set up a meeting with my CEO to communicate that we will have to spend ~250% more on our cloud service bill in about 60 days.

Actually, google increased the pricing by 1400% and gave 60 days to rewrite, migrate, move out or perish!  

The closest competitor in terms of capability was DistanceMatrix and a reliable “Large” player was Bing. But, both left a lot for in the “Accuracy”. So, for us, the business decision was simple: make the entire product work in “Reduced Functionality” mode for all or start differential pricing for better accuracy!  In either case, those APIs must be rewritten with a new adaptor. 

It is not an enigma why we do this. It’s simple: there are no alternatives, there is no time to GTM,  But maybe there is. I’ll explain why you should take cloud-agnostic architecture seriously and then show you what I do to keep my projects cloud-agnostic.

Cloud Service Rationalisation

The prime reason you should consider the ability to switch clouds and cloud services is so you can choose to use the cloud service that is price and performance-optimized for your use case.

When I first got into serverless, we wrote a transformative API on Oracle Cloud (Bcoz we were part of their Accelerator Program and had a huge credit.) but it fed part of the data that the customer-facing API relied on.

No prize for guessing what happened?

It was a horrible mistake. Our API had an insane latency problem. Cold start requests added additional latency of at least 2 seconds per request. The AWS team has worked hard to build a service that can do things that GCP’s Cloud Functions simply can’t, specifically around cold starts and latency.

I had to move my infrastructure to a different service and a revised network topology.

Guess we would have learned the problem by now, but as we will find out, we did not.

This time it was a combination of Kafka and the AWS Lambda that created an issue. We had relied on Confluent’s connectors for much of the workload interfaces and had to shell out almost $1000 per month per connector!

Avoiding the Cloud Provider Killswitch

Protect Your Business from Unexpected Termination

As a CXO, you may not be aware that cloud providers like AWS, GCP, and Azure reserve the right to terminate your account and destroy your infrastructure at any time, effectively shutting down your business operations. While this may seem like an extreme measure, it’s important to understand that cloud providers have strict terms of service that can lead to account termination for a variety of reasons, even if you’re not engaged in illegal or harmful activities.

A Chilling Example

I recently spoke with a friend who is the founder of a fintech platform. He shared a chilling incident that highlights the risks of relying on cloud providers. His team was using GCP’s Cloud Run, a container service, to host their API. They had a unique use case that required them to call back to their own API to trigger additional work and keep the service active. Unfortunately, GCP monitors this type of behaviour and flags it as potential crypto-mining activity.

On an ordinary Sunday, their infrastructure vanished, and their account was locked. It took them six days of nonstop effort to migrate to AWS.

Protect Your Business

This incident serves as a stark reminder that any business operating on cloud infrastructure is vulnerable to unexpected termination. While you may not be intentionally engaging in activities that violate cloud provider terms of service, it’s crucial to build your infrastructure with the possibility of termination in mind.

Here are some key steps you can take to protect your business from the cloud provider killswitch:

  1. Read and understand the terms of service for each cloud provider you use.
  2. Choose a cloud provider that aligns with your industry and business model.
  3. Avoid relying on a single cloud provider.
  4. Have a backup plan in place.
  5. Regularly review your cloud usage and ensure compliance with cloud provider terms of service.

By taking these proactive measures, you can significantly reduce the risk of your business being disrupted by cloud provider termination and ensure the continuity of your operations.

Unleash the Power of Free Cloud Credits

For early-stage startups operating on a shoestring budget, free cloud credits can be a lifeline, shielding your runway from the scorching heat of cloud infrastructure costs. Acquiring these credits is a breeze, but the way most startups build their infrastructure – akin to an unbreakable blood oath with their cloud provider – restricts them to the credits granted by that single provider.

Why limit yourself to the generosity of one cloud provider when you could seamlessly switch between them to optimize your resource allocation? Imagine the possibilities:

  • AWS to GCP: Upon depleting your AWS credits, you could effortlessly migrate your infrastructure to GCP, taking advantage of their generous $200,000 credit offer.
  • Y Combinator: As a Y Combinator startup, you’re entitled to a staggering $150,000 in AWS credits and a mind-boggling $200,000 on GCP.
  • AI-Powered Startups: If you’re developing AI solutions, Azure welcomes you with open arms, offering $300,000 in free credits to fuel your AI models on their cloud.

By embracing cloud-agnostic architecture, you unlock the freedom to switch between cloud providers, potentially saving you a significant $200,000 upfront. Why constrain yourself to a single cloud provider when cloud-agnosticism empowers you to navigate the cloud landscape with flexibility and cost-efficiency?

Building Resilience: The Importance of Cloud Redundancy

In the ever-evolving world of technology, no system is immune to failure. Even industry giants like Silicon Valley Bank can outright disappear over a weekend or AWS’ main Datacenter can go offline due to a power fluctuation, highlighting the importance of proactively safeguarding your business operations.

Imagine the potential financial impact of a 12-hour outage on AWS for your company. The costs could be staggering, not only in lost revenue but also in reputational damage and customer dissatisfaction or even potential churn.

This is where cloud redundancy comes into play. By running parallel segments of your platform on multiple cloud providers, such as AWS and GCP, you’re essentially creating a fail-safe mechanism.

In the event of an outage on one cloud platform, the other can seamlessly pick up the slack, ensuring uninterrupted service for your customers and minimizing the impact on your business. Cloud redundancy is not just about disaster preparedness; it’s also about optimizing performance and scalability. By distributing your workload across multiple cloud providers, you can tap into the unique strengths and resources of each platform, maximizing efficiency and responsiveness.

In our case, we run the OCR packages, SAML, and Accounts service on Azure, our core “Recommendation engine” and “Booking Engine” on AWS. Yes, having a multi-cloud will involve initial costs that might be prohibitive, but in the long run, the benefits will far outweigh the costs.

Cloud Cost Negotiation: A Matter of Leverage

In the realm of business negotiations, the ultimate power lies in the ability to walk away. If the other party senses your lack of alternatives, they gain a significant advantage, effectively holding you hostage. Cloud cost negotiations are no exception.

Imagine you’ve built a substantial $10 million infrastructure on AWS, heavily reliant on their proprietary APIs like S3, Cognito, and SQS. In such a scenario, walking away from AWS becomes an unrealistic option. You’re essentially at their mercy, accepting whatever cloud costs they dictate.

While negotiating cloud costs may seem insignificant to a small company, for an organization with $10 million of AWS infrastructure, even a 3% discount translates into substantial savings.

To gain leverage in cloud cost negotiations, you need to establish a credible threat of walking away. This requires careful planning and strategic implementation of cloud-agnostic architecture, enabling you to seamlessly switch between cloud providers without disrupting your operations.

Cloud Agnosticism: Your Negotiating Edge

Cloud-agnostic architecture empowers you to:

  1. Diversify your infrastructure: Run your applications on multiple cloud platforms, reducing reliance on a single provider.
  2. Reduce switching costs: Design your infrastructure to minimize the effort and cost of migrating to a new cloud provider.
  3. Strengthen your negotiating position: Demonstrate to cloud providers that you have alternative options, giving you more bargaining power.

By embracing cloud-agnosticism, you transform from a captive customer to a savvy negotiator, capable of securing favorable cloud cost terms.

Unforeseen Challenges: The Importance of Cloud Agnosticism

In the dynamic world of business, unforeseen challenges (and opportunities) can arise at any moment. We often operate with limited visibility, unable to predict every possible scenario that could impact our success. Here’s an actual scenario that highlights the importance of cloud-agnostic architecture:

Acquisition Deal Goes Through

This happened with One of my previous organisations, we tirelessly built this company from the ground up. Our hard work and dedication paid off when a large SaaS Unicorn approached us with an acquisition proposal.

However, during the due diligence, a critical issue emerged: Our company’s infrastructure was entirely reliant on AWS. The Acquiring company had a multi-year multi-million dollar deal with Azure and the M&A team made it clear that unless our platform can operate on Azure, the deal is off the table!

Our team faced the daunting task of migrating the entire infrastructure to Azure within a limited timeframe and budget. Unfortunately, the complexities of the migration proved time-consuming and the merger took 5 months to complete and the offer was reduced by $2 million!

The Power of Cloud Agnosticism

This story serves as a stark reminder of the risks associated with a single-cloud strategy. Had our company embraced cloud-agnostic architecture, we would have possessed the flexibility to seamlessly switch between cloud providers, potentially leading to a bigger exit for all of us!

Cloud-agnostic architecture offers several benefits:

  • Reduced Vendor Lock-in: Avoids dependence on a single cloud provider, empowering you to switch to more favourable options based on your needs.
  • Improved Negotiation Power: Gains leverage in cloud cost negotiations by demonstrating the ability to switch providers.
  • Increased Resilience: Protects your business from disruptions caused by cloud provider outages or policy changes.
  • Enhanced Scalability: Enables seamless expansion of your infrastructure across multiple cloud platforms as your business grows.

Embrace Cloud Agnosticism for Business Continuity

In today’s ever-changing technological landscape, cloud-agnostic architecture is not just a benefit; it’s a necessity for businesses seeking long-term success and resilience. By adopting a cloud-agnostic approach, you empower your company to navigate the complexities of the cloud landscape with agility, adaptability, and cost-efficiency, ensuring that unforeseen challenges don’t derail your journey.

My Solution

Here’s what I do about it, now after the lessons learnt. I use Multy. Multy is an open-source tool that simplifies cloud infrastructure management by providing a cloud-agnostic API. This means that developers can define their infrastructure configurations once and deploy them to any cloud provider without having to worry about the specific syntax or nuances of each cloud platform. While Multy provides an abstraction layer for deploying cross-cloud environments, you will also need to incorporate cloud-environment agnostic libraries to really make a difference.

References & Further Reading: 

  1. https://kobedigital.com/google-maps-api-changes/
  2. https://www.reddit.com/r/geoguessr/comments/cslpja/causes_of_google_api_price_increase_suggestion/ 
  3. https://multy.dev/
  4. https://github.com/multycloud/multy
  5. https://github.com/serverless/multicloud 
  6. https://aws.amazon.com/startups/credits
Achieve Peak Performance: AI Tools for Developers to Unlock Their Potential

Achieve Peak Performance: AI Tools for Developers to Unlock Their Potential

By | | Comments 0 Comment

You were scrolling through Twitter or your favourite SubReditt on the latest tech trend and a sudden feeling of FOMO creeps in. You’re not alone.

While the notion of a “10x developer” has traditionally been considered aspirational, the emergence of AI-powered tools is levelling the playing field, empowering developers to achieve remarkable productivity gains. While there might be 1000s of possible “AI tools”, I’ll restrict to tools which could yield a direct productivity boost to a developer’s day-to-day work as well as the outcome.

1. AI Pair-Developer / Code Assistants

Sourcegraph Cody & Github Copilot — Read, write and understand code

If you have used GitHub Copilot. Think of a Cody as a Turbocharger for Copilot. If you have not used Copilot, you should first try it. Either of these can understand your entire codebase, code graphs, and documentation and help you write efficient code, write unit tests, and document the codebase for you.

While the claim of a 10x speed increase is not substantiated, it shows clear intent to improve productivity drastically. However, it’s in beta, and the tool acknowledges that it’s not always correct, though they’re making rapid improvements. Yes, GitHub Copilot X is there — but then, your organisation needs to be on the Enterprise plan or you might have to add an additional $10-20 per user per month, and Cody is already here.

2. AI Code reviews – Offload the often mundane task of code reviews

While CodeRabbit and DeepCode (now acquired by Snyk) are some of the trailblazers in this space, I have not had the opportunity to work with either of them for any stretch of time. If you know about their relative strengths or benefits, please add a comment, and I will incorporate it.
The tool I use most regularly is called Robin-AI-Reviewer, from the good folks at Integral Healthcare (funded by Haystack). My reasoning is two-fold, It is open-source and if it is good enough for HIPPA-compliant app development and certification assessment, it’s a good starting point.

3. AI Test writing – Delegate the task of writing tests to AI- CodiumAI

CodiumAI serves as an AI test-writing assistant. It analyses your code, docstrings, and comments to suggest tests intelligently. CodiumAI addresses a critical aspect of software development that often consumes valuable time: testing. While numerous tools prioritize code writing and optimization, ensuring code functionality is equally vital. CodiumAI seamlessly fills this gap, and its intelligent test generation capability can substantially enhance development efficiency and maintain superior code quality.

4. AI Documentation Assistant — Get AI to write docs for you

This is a no-brainer, who loves writing code walkthroughs and docs? No? Didn’t think so! Mintlify serves as your team’s technical writer. It reads and interprets your code, turning it into a clear, readable document. By all accounts, it is a definite must.

Disclaimer: I have not personally used this and have been mostly able to get this done with Cody, itself. And then, I am no longer doing the primary documentation as my main responsibility.

5. AI Comment Assistant – Readable AI — Never write comments again

Readable AI automates the process of generating comments for your source code. It’s compatible with several popular IDEs, like VSCode, Visual Studio, IntelliJ, and PyCharm, and it can read most languages.

6. AI Tech Debt Assistant – Grit.io

Grit.io is an automated technical debt management tool. Its prime function is auto-generating pull requests that manage code migrations and dependency upgrades. Grit is in beta and available for free till beta moves to RC1. But it actually has about 50+ pattern libraries and it is growing.

I absolutely love it and Grit alleviates a significant portion of the manual work involved in managing migrations and dependency upgrades. They say it 10x’s the refactoring and migration process. I’d say at 33% of what they say, It will still be 300% of what productivity increases. And it is a considerable gain. If you’re an Engineering Leader and you have a “Budget” for 1 tool only, It should be this!

7. AI Pull Request Assistant – An “AI” powered DIff tool

What The Diff AI is an AI-powered code review tool. It writes pull request descriptions, scrutinises pull requests, identifies potential risks, and more. What The Diff claims to be able to significantly speed up development timelines and improve code quality in the long run. It could take a great deal of pain out of the process.

Disclaimer: I have not personally used this

8. AI-driven residential Wizard – Adrenaline AI — Explain it to me

Adrenaline AI helps you understand your codebase. The tool leverages static analysis, vector search, and advanced language models to clarify how features function and explain anything about it to you. The thing I like about this tool very much is, it can be leveraged to automate the “How tos” for your software engineering teams!

9. AI collaboration companion for software projects

Stepsize AI by Stepsize is an AI companion for software projects. It seamlessly integrates with tools like Slack, Jira, and GitHub, providing insightful overviews of your activities and offering strategic suggestions.

The tool uses a complex AI agent architecture, providing long-term “memory” and a deep understanding of the context of your projects.

10. AI-Driven Dev Metrics Collection – Hivel.ai

While strictly speaking, not an AI-driven “assistant” to an average developer, I feel it is nevertheless a good tool for the Engineering org and Engineering leaders to keep track and make course corrections. It provides a Cockpit/Dashboard of all the metrics that matter.

Hivel is built by an awesome team of devs and led by Sudheer

Bitnami