This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

News About Skyramp

🌟 Elevate Your Microservices Game with Skyramp's Latest Insights! 🚀

By Skylar |

Hey there, Amazing Developers! 👋

Hope you’re coding wonders! At Skyramp, we’re always excited to share insights that can revolutionize your development journey, and today is no exception! 🎉

🌐 Introducing our latest blog: “Microservice Dependencies with Skyramp”. It’s not just a blog; it’s your new playbook in the ever-evolving world of microservices.

Read the Blog Here 📖

As you weave through the intricate web of microservices, you’re faced with the daunting task of managing dependencies - a crucial, yet often challenging aspect of development and testing. But worry not! 🛠️💡 We’ve got your back.

Our blog dives deep into the art of mocking dependencies. Yes, those tricky parts of distributed applications that offer amazing flexibility and scalability but can be a headache to handle. Skyramp steps in as your ally, providing effective and innovative ways to mock these dependencies, ensuring your development process is not just smooth, but also more efficient than ever. 🚀

Here’s what you’ll uncover in the blog:

  • Insightful Strategies: Learn how to tackle dependencies in microservices like a seasoned pro.
  • Practical Solutions with Skyramp: Discover how our tool can transform your development workflow.
  • Variety of Choices: Explore the numerous options at your disposal for mocking dependencies effectively.

This blog is more than just a read; it’s a resource that empowers you to master the complexities of microservice dependencies with confidence and ease. 📚✨

So, what are you waiting for? Dive into our blog, and let’s make your development process not just effective but enjoyable! 🎈

Stay innovative, stay ahead!

Your friends at Skyramp

P.S. We love hearing from you! Share your thoughts or experiences with Skyramp in your projects. Let’s keep the conversation going! 💬

Banner

Embrace the Future of Microservices Testing with Docker Compose and Skyramp! 🚀

By Skylar |

Hey fellow developers! 👋

I wanted to share an intriguing find from a recent dev.to post: “Jump into Microservices Testing with Docker Compose and Skyramp.” Skyramp, a specialized testing tool for distributed systems, is changing the game in microservices testing.

Here’s the kicker: While much of the buzz has been about Kubernetes integration, Skyramp proves to be far more versatile. It’s fully capable with Docker Compose, offering an alternative to Kubernetes without sacrificing the benefits of test automation.

What stands out is Skyramp’s comprehensive feature set, designed to automate testing across various components within a microservices ecosystem. This isn’t just about simplifying processes; it’s about enhancing efficiency and effectiveness in a landscape where microservices are becoming increasingly complex.

The article delves into how you can leverage Skyramp alongside Docker Compose to streamline your testing efforts. It’s not just about adopting new tools; it’s about adapting to an evolving tech environment with smarter, more efficient solutions.

Read it here: https://bit.ly/414dsXD

Would love to hear your thoughts on this. Are you considering integrating Skyramp with Docker Compose in your workflow? Let’s discuss how this could impact our development practices!

Banner

⚡️ Observe This: One Step from Trace to Test with Skyramp ⚡️

By Skylar |

Our latest blog post, fresh from the insights of KubeCon North America 2023, is a must-read. 📚

This piece dives deep into how easy it is to use Skyramp to leverage observability tracing, a hot topic at the recent KubeCon, to increase functional code coverage for your distributed apps

Read it here 👉 https://bit.ly/46jE2gL 👈

🔗 Join the conversation on how observability, tracing, and testing are reshaping the landscape of distributed applications. Read, engage, and share your thoughts with fellow professionals in the field. #KubeCon2023 #Skyramp #Observability #Kubernetes #SoftwareDevelopment #TechInnovation 🚀💻

Banner

📢 3 Tools to Improve Your Code Quality: GitHub Codespaces, Kubernetes, and Skyramp 🚀

By Skylar |

In the world of developing distributed applications with microservices, code quality is paramount. 🌟 Don’t settle for anything less than the best! 💪

Join us as we dive into the power of GitHub Codespaces, Kubernetes, and Skyramp - three powerful tools that will enable you to create an instant, seamless dev environment and rapidly find functional and performance issues among microservices as you build. 🛠️

Read here 👉 https://bit.ly/3QHGysn 👈

Remember, component testing plays a crucial role in ensuring your distributed application works flawlessly. 💡 And Skyramp is here to lend a helping hand in this critical stage of testing. 🙌

Don’t miss out on this must-read blog! 💻 Improve your code quality and build robust applications that shine! ✨

Banner

🌟 Test Generation for Distributed Apps Made Easy with Kubernetes, OpenAPI, and Skyramp 🌟

By Skylar |

In the ever-evolving world of software development, the importance of testing to ensure quality cannot be overstated. This rings especially true when it comes to distributed applications and microservices. Distributed applications bring a host of complexities that require a thoughtful approach to testing. But fear not, fellow developers! We have some groundbreaking news to share with you today.

Skyramp! 🚀 is a simple yet powerful testing tool that leverages technologies like Kubernetes and OpenAPI to streamline the process of test generation for distributed applications, making it easier and more efficient than ever before.

📝 Want to see how it works? Check out our latest blog post where we dive into a step-by-step example using Skyramp and these industry standards!

🔗 Read more: Test Generation for Distributed Apps Made Easy with Skyramp

With Skyramp, the once cumbersome task of meaningful test generation for distributed applications becomes a breeze. Say goodbye to manual test case creation and hello to increased productivity and efficiency!

Lab test

🔥 Hot Code Reload: Revolutionizing the Debugging Process! 🔥

By Skylar |

Are you tired of the traditional, cumbersome debugging process that requires re-deployments of microservices every time you want to test a code change? We’ve got fantastic news for you! Skyramp, the creators of Test Easy for distributed applications, now offers a game-changing feature known as Hot Code Reload. 🚀

With Hot Code Reload, gone are the days of interrupting your workflow to make minor code tweaks. Now, you can debug your services in real-time without the hassle of re-deploying your application. 🙌

Here’s how it works: Imagine attaching your debugger, stepping through code, and making changes - all while your service continues to run smoothly without a single interruption. Sounds like a dream, right? Well, it’s now a reality with Skyramp’s Hot Code Reload!

In today’s blog post, we’ll tackle the setup process for Hot Code Reload in any Kubernetes environment. We’ll guide you through a specific example using GitHub Codespaces. 🖥️💡

🌐 Read about Hot Code Reload here 👉 Turbocharge Your Debugging with Skyramp’s Hot Code Reload

By following our detailed instructions, you’ll be able to witness the magic of Hot Code Reload yourself. 🐞✅

So, don’t wait any longer – dive into our blog post now and discover how to leverage Hot Code Reload to supercharge your development and debugging workflow for distributed applications. Your future self will thank you! 🙌🔥

Debugging

🌟 All your Tests and Mocks in One Place with Skyramp Dashboard 🌟

By Skylar |

👉 Are you tired of juggling between different tools and platforms for integration and performance testing of distributed applications? Look no further, because Skyramp has got you covered with the game-changing Skyramp Dashboard, designed to simplify your testing process and boost productivity like never before. 🎉

🔥 Say goodbye to the chaos of scattered test results. Stop losing track of mocks. With the powerful Skyramp Dashboard, you can now effortlessly monitor and manage all your test runs and mock configurations. 📊✅

✨ Join us as we take a deep dive into the incredible capabilities of the Skyramp Dashboard, specifically tailored for testing microservices in a Kubernetes cluster. 🚀💡

🔍 Discover how Skyramp empowers developers and DevOps engineers to streamline their testing workflows, ensuring seamless integration and top-notch performance of distributed applications. This article is a must-read. 👀📚

🌐 Read about the Skyramp Dashboard here 👉 All your Tests and Mocks in One Place with Skyramp Dashboard

👨‍💻 Don’t miss out on learning how Skyramp Dashboard can revolutionize your testing journey. Join the Skyramp community of forward-thinking devs, and unleash the true potential of your distributed applications. 💪🌟

Test Tubes

🚀 Exciting news for Python developers! 🐍🎉

By Skylar |

Skyramp, the renowned testing and mocking tool for distributed applications, has now added support for Python code! 🎊 Previously, Skyramp only supported JavaScript for dynamic requests and responses within test and mock description files. But now, Python enthusiasts can leverage the power of this tool to dynamically test and mock their microservices. And the best part? It all happens seamlessly from a running Kubernetes cluster! 🌟

Not only does this update broaden Skyramp’s horizons, but it also opens up a world of possibilities for Python developers like you. With the ability to employ dynamic Python code in requests and responses, you can ensure that your microservices are thoroughly tested and mocked, without breaking a sweat. 💪

Read more here: Skyramp Feature Highlight: Using Dynamic Python for Tests and Mocks

So, how does this groundbreaking capability work? Let’s dive in!

1️⃣ First, you’ll need a running Kubernetes cluster. If you’re already familiar with Skyramp, you know that it works like magic within the Kubernetes environment. Just imagine all the possibilities that await you in this containerized world!

2️⃣ Next, it’s time to wield the power of dynamic Python code. With Skyramp’s new feature, you can dynamically modify HTTP requests and responses in your test and mock description files, using Python. This means you have the flexibility to handle any complex scenario with ease, right from your cluster. No more limitations, no more compromises.

3️⃣ Finally, reap the benefits! By deploying Skyramp with Python support, you’ll experience a seamless testing and mocking process for your distributed applications. Say goodbye to painstaking manual testing and mocking, and say hello to increased productivity and peace of mind. Skyramp empowers you to build and maintain robust microservices effortlessly.

In conclusion, Skyramp’s integration of dynamic Python code is a game-changer for Python developers. It brings a new level of flexibility and convenience to testing and mocking microservices in a distributed environment. With the power of Skyramp and the versatility of Python, you can take your development practices to new heights. 🚀

So, what are you waiting for? Dive into Skyramp’s new Python capability today and unlock the true potential of your distributed applications. Share your experiences, and let’s revolutionize the world of testing and mocking together! 🌟

Test Tubes

Hot Code Reload for Fast Microservices Debugging

By Skylar |

In our latest video, we walk through testing and debugging microservices in a Kubernetes cluster with Skyramp’s hot code reload feature, which makes it easy to iteratively test and debug your code quickly. The hot code reload feature seamlessly enables real-time debugging while simultaneously testing your microservices without redeployments.

Testing Microservices with Skyramp in IntelliJ IDEA

By Skylar |

When we say Skyramp meets devs in any workflow, we mean it. Do you develop distributed apps with Java and IntelliJ IDEA? This new blog post demonstrates iterative testing and development for microservices in a local Kubernetes cluster with Skyramp performed directly from IntelliJ IDEA. Read Testing Microservices with Skyramp in IntelliJ IDEA to learn how Skyramp makes distributed app testing quick and easy.

Test Flight

Easily test and mock microservices using Docker and GitHub Codespaces

By Skylar |

Skyramp makes it easy for devs to test & mock microservices using Docker in any dev environment with GitHub Codespaces. Watch our new video to see just how easy it is.

Introducing Tester: Easily Test Combos of Microservices Underlying your Distributed App

By Mia |

Today we’re announcing the availability of Tester as part of Skyramp’s VS Code Extension. Our API test client makes it easy to create and run functional integration and load tests against hard-to-reach endpoints inside your application. Quickly execute complex test scenarios with request chaining and powerful asserts. Save time and stop writing flaky end-to-end tests. Tester makes experimenting with your app fast, easy, and above all — useful.

Test Easy in Any Environment with GitHub Codespaces

By Skylar |

Skyramp makes it easy for devs to test distributed apps for function and performance — on their own, with surrounding dependencies, under real-world conditions. In this video we show how easy it is to test and mock microservices in Kubernetes clusters in any dev environment using GitHub Codespaces and Skyramp Distributed TestKit.

Watch the video below, and then get started with Skyramp for CLI or VS Code.

Mocker: Proxy Power for gRPC Development

By Mia |

Over the past few weeks we’ve been walking you through some of the great use cases for Mocker, the first of our Kubernetes testing tools in our VS Code extension, Kubernetes Test Toolkit.

Today I want to walk you through its powerful gRPC proxying capability. You can easily mock a subset of the methods in an endpoint, while directing others to the live service in your cluster, enabling more realistic, more meaningful tests.

Imagine you’re developing an e-commerce website with a microservice architecture. Today, we’ll focus on the product service catalog service, responsible for displaying products to customers.

Application Map with Product Catalog Highlighted

Say we want to mock the ListProducts and SearchProducts methods using Mocker. By defining mock data, we simulate various product scenarios, ensuring our frontend components and layouts work as expected.

YAML File

However, when it comes to fetching real product details for individual product pages, we want the latest information. We configure Mocker to proxy the GetProduct method to the live service by setting proxy equal to true. From now on, all requests are forwarded to the live service.

Set Proxy equal to True

Once we’re done editing, we save the changes and deploy the mocks. With Mocker in place, our frontend seamlessly interacts with mocked methods while retrieving real data for product searches.

Mock configuration is deployed

This proxy functionality helps you streamline your development with gRPC proxying. Mocker is free to use and available now on the VSCode extension marketplace.

Coming soon – Tester, the perfect test client complement to Mocker. Tester makes it easy for devs to go beyond unit testing and generate and run complex scenarios for comprehensive services testing. Sign up here to be among the first to hear when we add this new toolkit capability!

Mocker Gives You Proxy Power to Streamline gRPC Development

By Mia |

Over the past few weeks we’ve been walking you through some of the great use cases for Mocker, the first of our Kubernetes testing tools in our VS Code extension, Kubernetes Test Toolkit.

Today I want to share a video with you that walks you through its powerful gRPC proxying capability. You can easily mock a subset of the methods in an endpoint, while directing others to the live service in your cluster, enabling more realistic, more meaningful tests.

Coming soon – Tester, the perfect test client complement to Mocker. Tester makes it easy for devs to go beyond unit testing and generate and run complex scenarios for comprehensive services testing. Sign up here to be among the first to hear when we add this new toolkit capability!

Switch from Live to Mock in Seconds with Mocker

By Mia |

Today I’ll be talking more about Mocker, our VS Code extension that simplifies service mocking in Kubernetes clusters.

Let’s say you’ve already used Skyramp to deploy your system under test in the cluster, which includes your live payment service. Before Mocker, changing from the live payment service in your cluster to a mock was a complex and time-consuming process. You had to create a new microservice called payment-mock, using the same API spec as the original. This involved writing a server stub to provide the desired response. Then, you had to deploy the mock service into the cluster, and update the networking to disconnect the existing payment microservice. If you wanted to change values, you had to rebuild the microservice and update it accordingly.

Mocker allows you to focus solely on the external configuration, while it takes care of all the internal cluster management through a single worker.

Simply connect your cluster to Mocker.

Connect your cluster

Effortlessly modify the return values in your mock configuration.

Modify values

Then hit deploy mocks.

Deploy mocks

Mocker handles all the heavy lifting behind the scenes, including managing gRPC communications. There’s no Kubernetes expertise required.

That’s it! You’ve switched from live to mock services in just seconds, all within your IDE. Doing it is probably faster than reading about it in this blog!

Coming soon – Tester, the perfect test client complement to Mocker. Tester makes it easy for devs to go beyond unit testing and generate and run complex scenarios for comprehensive services testing. Sign up here to be among the first to hear when we add this new toolkit capability!

Mocker: Easy Live-to-Mock Switching in VS Code

By Mia |

Today we’re showing how easy Mocker makes it to switch from a live service running in your cluster to a mock. It only takes a few seconds using this VS Code extension that simplifies service mocking in Kubernetes clusters.

Here’s a super-short video showing how easy it is to switch from live to mock in seconds.

Watch: 60 Seconds to In-Cluster Mocks

By Mia |

Hi, it’s Mia again. A few weeks ago we announced the availability of the first of our Kubernetes testing tools, Mocker on the VS Code extensions marketplace.

Today we’ve got a video walkthrough to show you how easy it is to mock a service running inside a cluster and debug if you already have your application deployed in that cluster.

Mocker Makes it Easy to Mock and Debug Inside a Cluster

By Mia |

Hi, it’s Mia again. A few weeks ago we announced the availability of the first of our Kubernetes testing tools, Mocker on the VS Code extensions marketplace.

Today I want to show you how easy it is to mock a service running inside a cluster and debug if you already have your application deployed in that cluster.

First, deploy a new worker container in the namespace where your application is running.

Screenshot of the first action

Second, once the worker container is deployed, you can create a mock in six easy steps:

Step 1. Enter a port number

Screenshot of entering a port number

Step 2. Select an API protocol

Screenshot of selecting an API protocol

Step 3. Choose the input API definition file

Screenshot of choosing a file

Step 4. Select a service to mock

Screenshot of selecting a service

Step 5. Enter the name of the K8s service that is running

Screenshot of entering the service name

Step 6. Review your choices, and confirm by clicking “Create Mock”

Screenshot of confirming selections

You’ll see a YAML of the generated configuration. If needed, you can edit default values here.

Third, apply the created mock. This will push the mock configurations to Mocker in-cluster. All calls to the mock service will now be routed to Mocker, which will respond with the configured default values.

If you’d like to update mock values, simply rerun the “apply mocks” command and change them.

We’ll have a video walkthrough of this entire process posted shortly!

If you have any feedback or requests, please let me know at support@skyramp.dev.

We are adding more features continually, as well as new Kubernetes testing tools to accompany Mocker, including:

  • a JS library to create complex in-cluster mocks
  • Tester, Mocker’s powerful test client partner

Sign up here to get notified of important new Skyramp launches and announcements.

Thanks,

Mia

Mock Service Dependencies in Kubernetes Clusters

By Mia |

Hi! I’m Mia, a product manager/engineer at Skyramp building tools that make it easy to test microservices in-cluster.

As a team of engineers with experience building cloud-native solutions at both startups and big co’s like VMWare, we are deeply aware of how frustrating it can be for devs to test their microservices in-cluster. One of the problems that has come up consistently as we have talked to developers is that of mocking service dependencies in a cluster. We narrowed down the problem to two use cases:

  1. Case 1: A company partners with third party service providers to get data (for example, market data for a fintech company) and has to deal with test versions of those third-party services in their pipelines. The SLAs for these “Test Nets” are non-existent and result in flaky tests. In addition to the flakiness, devs cannot rely on these test networks when they have to run load tests. In each case, there is some amount of work involved in mocking out the dependency so the work never gets done.

  2. Case 2: If a developer (particularly someone working with gRPC) wants to isolate their microservice for debugging an issue in-cluster, they will need to work with Kubernetes networking (fun for some of us, not for others :) ) and then deal with tons of boilerplate code to get it working.

We figured that we would start small and reduce the toil in getting in-cluster mocks going, so we created Mocker — an in-cluster mock server for gRPC and REST.

You can use Mocker either via the CLI or as a VSCode extension. These clients rely on our Worker that is deployed in your cluster via Helm. You can create mock configurations by simply pointing Mocker to your OpenAPI spec or your .proto files. These configurations are pushed to Worker which takes care of the networking inside the cluster to seamlessly help you switch between the mock and live versions of your dependency.

We’ve also built an OpenAI integration which can help you generate realistic mock data so you’ve got one less thing to worry about.

To sum it up, here is what you can do with Mocker:

  1. Automatically create mock configurations: Simply point Mocker to the API file and get going!
  2. Turnkey Mock Values: Mocker auto generates mock values that you can edit as needed. The CLI version has support for OpenAI generated mock values.
  3. Complex mocks via Javascript support: Simulate dynamic mock responses for complex test cases by pointing to a Javascript file with the behavior.
  4. gRPC Proxy: For gRPC services, Mocker acts as a proxy that allows you to selectively mock a subset of the methods in an endpoint, while directing others to the live service in your cluster.
  5. VSCode Extension for a streamlined UI based experience designed to keep you in your workflow.
  6. Coming soon: Out of the box support for generating latencies and error codes for testing failure cases.

We still have a lot of work ahead of us but would be grateful for any feedback or suggestions at support@skyramp.dev.

If you want to follow our journey and see what else we are up to, sign up here.

Three Tenets of Test Easy — 3. Sharing is Caring

By Skylar |

Let’s talk building tests. In particular, testing in the inner dev loop. When was the last time you felt inclined, or even compelled, to share those tests with your team? Or even other teams. I’m guessing you can’t recall. Because these quick & dirty creations aren’t really meant for public consumption. So all that effort is one-time, and often wasted.

At Skyramp we’re passionate about putting the power of cloud native testing into the hands of devs. Some of that involves taking all the tedious work around testing — test packaging, payload creation, and even the requisite networking tasks — off of your plate. Giving you tools like powerful, in-cluster gRPC and REST mocking that makes it easy to build complex, dynamic in-cluster mocks.

But when you test the easy way with Skyramp, and you build some great test components (for example, mocks), you’re doing work that many of your teammates would love to reuse. For tests in the inner loop, or pipeline. Doesn’t matter. Chances are, even other teams could really benefit. If you think about it, collaborating around powerful cloud native tests and components makes you a collaborator. But you’re more likely to get props from teammates for the assist vs. a bullet. Nice!

Skyramp is dedicated to exploring and embracing ways to allow you to do just that: accelerate Test Easy through the joys of test collaboration. Watch this space to learn more, because this stuff is coming sooner than you think.

Three Tenets of Test Easy — 2. Stop Squinting

By Skylar |

In last week’s blog we talked about the first rule of Test Easy: modularity. No more cut & paste. If shift left testing is going to be a thing, it’s got to be easy, and modularity of test design goes a long way to ensuring this easy — for devs of all skill levels, across the CI CD pipeline for who care about testing microservices and APIs in the context of cloud native software development.

Modularity makes the second rule of Test Easy easier to achieve: readability. Software readability is, of course, related to the comprehension of text, and it’s essential for software maintenance. Testing frameworks are no exception to this rule.

When it comes to Test Easy, readability has many contributing factors. Above all it’s about doing things in a way developers and others invested in shift left microservices testing find familiar. Some might call this “meeting X where they are” but we won’t engage in derivative language groupthink in this blog. Test Easy has to provide comfort at every skill level. Comfort at every stage of the CI CD pipeline. Comfort, by using the most popular languages for building. Comfort, by dispensing with the need for a whole new DSL.

Readability requires a glanceable testing framework where it’s easy to understand both the building block modules and the entire test design. A framework that supports both integration and load tests as table stakes for cloud native app testing. That makes it easy to pull from a comprehensible library and use the same readable test design, or reconfigure it to better meet your testing needs.

Test Easy is modular, and it’s readable. And these two essential tenets converge to deliver the third essential element. Which we’ll cover in next week’s blog!

Three Tenets of Test Easy — 1. No More Cut & Paste

By Skylar |

The first rule of test club is to not treat developing tests any differently than developing software. We all know that is far from the case today. Best practices apply here. While cut & paste is frowned upon in best-practices software development, it’s pretty common for modern app developers (and others, we’re looking at you QA) to kludge together Frankenstein code for testing APIs and microservices.

Not only does this reduce the reliability of tests, it severely limits their longevity and shareability — which are tantamount to limited reusability.

So what’s the opposite of cut & paste? What’s the foundation of Test Easy? It’s modularity, my friend. And Skyramp is built from the ground up to embrace it.

But modularity isn’t an island. Test Easy requires more. Modularity unlocks the door to get there, but you’ll have to wait until the next blog to find out where it takes you.

Check Your Surroundings

By Skylar |

There’s a reason we say Skyramp, at its core, gives developers confidence. Not convenience, or ease, or power, or any other hyperbolic marketing gibberish. Just confidence. But why?

Because when it comes to testing your cloud native app, a solution you can’t rely on may be worse than worthless. The point of knowledge often hinges on the accuracy of that knowledge.

And in the modern app era, most testing solutions aren’t built from the ground up to account for all the cloud native nuances that must be considered to know how your app will function in production. Like the infrastructure on which it’s running. Like the fact that apps today must be built for scale, so integration testing must be done side-by-side with load testing. Knowing that your app will perform well — not just in your unit tests, but with the environmental variables and settings it will encounter in production — is the key to confidence.

Now, not all players in the software development, integration, and delivery process (the whole CI CD pipeline), care about the same things when testing cloud native apps. It makes sense that while devs might care about a subset of infrastructure services, for example, QA might care about more. So Skyramp is designed to make it easy for developers to stand up just their services under test and a desired number of mocks, while allowing others to stand up a larger assortment of services and a more comprehensive set of mocks. The bar for confidence rises with the user’s scope of responsibilities, and Skyramp rises with them.

In an upcoming blog we’ll talk more about what we mean by integration tests, specifically the narrow vs. broad distinction, the interplay with inner and outer dev loops, etc. Until then, Test Easy to stay confident!

Testing That's Cloud Native to the Core

By Skylar |

The shift to modern app development has done a lot to improve developer efficiency, and that’s a great thing. But it’s a little bit like the second law of thermodynamics: if you create order somewhere, you create chaos somewhere else.

In this case, it’s the dysfunction that can happen when pieces of code written by different teams come together. This potential for problems increases when different microservices mix with different infrastructures in different environments — from the outer dev loop all the way to production. If it’s cloud native and running in AWS or other CSPs there are even more cloud native infrastructure elements in the mix that can create dysfunction.

Shift left testing can only accomplish Test Easy if it does two things. One is to reduce the effort required by devs to design and run tests, and understand and share their output.

The other is to consider, often through abstraction, those infrastructure and cloud native elements that give their tests meaning, giving them and others in the CI CD pipeline confidence.

There are many things that can be done to support these two pillars of Test Easy. Particularly on the “testing built for modern apps from the ground up” front. We’ll talk more about them in upcoming blogs.

Do Devs Get Writer's Block?

By Skylar |

I’ve always imagined a sort of similarity between writing copy and coding. There is a strong vein of creativity running through both functions. In both cases, it usually takes a bit of time between sitting at the keyboard and getting into the zone. And once you’re in the zone, things just flow. Don’t interrupt me.

And while devs might not encounter writer’s block per se, they certainly can be less-than-inspired at times. And it’s the little things that can impede them. Little, annoying impediments that make it difficult to get into that full stride that only happens in the zone.

From the Skyramp POV, we think many of these tiny, cumulative impediments get in the way of good testing. For example, mocks that come pre-loaded with garbage values (or even creating functional mocks for that matter). What if we could really understand the system under test and go from garbage to golden with values that effortlessly make sense?

Another impediment are mocks and tests that don’t live in sensible places — the repos and clusters where your stuff already exists. What if we could fix that so there are not proprietary walled gardens, and all of this testing goodness becomes easy to share and use?

And API frameworks. When you’re used to REST but you’ve got to build using Thrift or gRPC.

And what about consistency? Sure, inner dev loop integration testing might focus on a narrower slice than broader outer loop testing. But wouldn’t it be less of a PITA if the same tools and code could just work across the whole CI CD pipeline?

When you come down to it, Skyramp is in the friction-reduction business. Testing can be a drag, but it doesn’t have to be. Everything we do is designed to make testing easier. And that makes it easier for devs to get into their zone, where the real magic happens.

Four Horsemen of the Kubernocalypse

By Skylar |

There are so many points of friction that can make testing microservices and APIs painful for developers, or QA, or anyone else in the CI CD food chain. Some of it has to do with Kubernetes and clusters, which some say has been making simple things complicated for many a year. Some pain comes from networking, which is rarely anyone’s favorite. Some have to do with mocking and standards like REST, gRPC, and Apache Thrift. And some of it is part and parcel of designing and building the cloud native application tests themselves, especially making them reusable/shareable and high ROI.

Problem is, different software pipeline participants have different ways and needs. Even among devs there is dissent about which of these four is particularly painful, and this usually stems from relative expertise. What is painful for some is easy for others.

Testing works best when it’s consistent among all software pipeline participants, regardless of skill level. When it’s easy to share. When it’s easy to design and deploy — low code or no code, ideally. A microservices testing solution that goes beyond simple unit testing needs to produce meaningful results, to democratize use, and to appeal to a wide audience must consider all these factors.

As we’ve built Skyramp, we’ve realized that one size does not fit all. What began as a single tool with multiple functions has evolved into simple, separate tools — each aimed at a specific point of pain, each with a single prevailing function.

And while there is undoubtedly room for glue that sticks all these tools together and unifies a multi-talented team around a common goal — delivering better cloud native software, faster — that will come in time. For now, let’s keep it simple: one tool to solve one testing pain, one step at a time.

Can We Trust Generative AI?

By Skylar |

I’ve always heard “trust but verify.” You can thank the KGB for this little gem, and I doubt those guys trusted anyone. I’ve always thought that the more accurate version was “trust BY verifying,” but I’ve never used sodium thiopental on anyone, so what do I know?

It seems as if the world is on fire about generative AI and large language models (LLM). And there are some interesting issues bubbling up to the surface. We all know the best lies are the ones mixed into a lot of truth. And those AIs do this really well, telling lies (or at least inaccuracies) with great panache and authority, all nestled among a barrage of competent prose — or software. It’s easy to dismiss the computer when it insists it’s 2022 and you KNOW it’s 2023. Silly silicon — until it starts swatting you. But what if you want to rely on these LLMs to build software?

We know a little bit about trusting software. At its core, Skyramp is about giving developers and other CI participants increasing confidence that the code that’s flowing into Kubernetes clusters will work once it reaches its ultimate destination. We do this by making it easier than ever before to introduce, share, and automate mocking and testing earlier and earlier into the software development process. Confidence comes from trust. And trust comes from both the sensitivity and specificity of testing cloud native applications. Sensitivity is about catching as much of the stuff that breaks things as possible. Specificity is about providing meaningful results once you catch them. You don’t have to be perfect to create trust and then confidence, but you have to do a lot better than doing nothing at all.

Which brings us to the original topic. More and more devs are using LLM to generate code. Skyramp is in the business of validating code, building developer trust and confidence. Is there an angle for Skyramp to do this for LLM output? And in a hat tip to Descartes, is there a world where LLM helps build Skyramp which helps validate LLM output?

Wouldn’t that be cool?

Not All Loads are Equal

By Skylar |

Some load tests are special cases. Take one of our startup design partners. For them, the point of scale tracks with the number of Kubernetes entities connecting to and writing to the particular microservice to be tested. In fact, this is his most-important load use case. Today, his tests are on-demand and manual. He creates multiple agents, and as he scales their number he keeps his eye on IO levels, UI data population, logs, and service resources. How much work would it take for him to manually design an automated test? Can we automate this in Skyramp to make this design partner’s life easier and spare him the one-off? Should we? It’s not just about mocking connecting services and writing loads. It has to do with the sequence of configuration, timestamped entries, and other complexities. We learn the most from concrete cases. Details can reveal a common denominator and a major use case. Or they can lead to corners we’d best avoid.

From Push to Pull

By Skylar |

In our march towards shift left and test easy for modern app developers, we’re always thinking of the obstacles our customers might encounter, and how we can reduce those barriers into rubble. Take the issue of data sourcing wrt to what’s needed to make it easy to test microservices, including easily mocking services in the system under test.

Skyramp today expects event-driven test inputs. But some use cases require the microservices under test to pull data, sometimes from variable sources. How can we support this? Is there a role here for generative AI? Stay tuned.

Invest in Success

By Skylar |

Skyramp thrives off complexity. Shift left testing of complex collections of microservices (including testing the Kubernetes infrastructure itself which is now essentially a part of the modern app), or single systems that need to function in multiple environments.

One of our design partners theorized that in most greenfield customer scenarios (i.e. new teams or new projects in a team), the simplicity of their use case might make Skyramp less useful. On demand, manual testing might suffice.

But everything evolves. Simplicity gives way to complexity. How might Skyramp evolve with the evolution of a customer or project? Nothing stays greenfield forever. Time to ask our partners to imagine and share.

Today, Testing Isn't Our Priority

By Skylar |

One of the side-effects of cloud native development and modern app pipelines is the expectation that devs do more. Call it the shift-left onus, or the Kubernetes krunch. It’s often the result of shrinking, or even disappearing, QA-only personnel.

You’re going to hear more from us about tools that are coming to make devs more efficient and alleviate this growing burden — and how we intend to make those tools much more reliable. Soon.

Still, it’s important to remember the point of giving devs time back. More time to code, sure. But also more time to enjoy life. Test easy so you can rest easy.

And today, at Skyramp, that’s exactly what we are doing. We have a new family member — the second child of our founder. And life, at least for today, is more than just about testing software.

Here’s to you, Nithin and Roshini.

Demo Projects that Don't Sock

By Skylar |

Eventually we’ll have a really cool sandbox or something similar for prospective developers to explore Skyramp, but for now we’re providing demo projects in multiple languages (REST, gRPC, and Thrift) to help get them started on their journey to shift let microservices testing and shipping code with confidence.

The funny thing is, there are precious few well-maintained projects out there that support all these standards. Actually, none we can find publicly. The best of the REST is WeaveSocks, and as much as we love those colorful knitted patterns, broken stuff like spotty M1 support has us frustrated.

Google seems to be keeping up support for Online Boutique for gRPC. So we added REST and Thrift support. Yeah we did! And we did this because we guessed the world wanted an open-source sample microservices application that could be used for cloud native application development, API testing, and microservices testing across different standard — REST, gRPC, Thrift.

So while we work on the easy way to test and solve integration and performance errors (shameless plug) among your many microservices and APIs — with reusability, modularity, and readability close to our hearts — we hope this multi-standard tool will be valuable for anyone who needs to build demos no matter their preferences.

Take a look.

Oh, and If you’re in the market for socks, we’d be happy to refer you to a few great sites.

Delivering Developer Ease: Air Gaps, Tech Debt, and Redacted Text

By Skylar |

We believe Skyramp offers value to cloud native app development in a number of areas. Much of this value is distilled into delivering ease and speed for developers. One value: identifying and standing up the system under test. Both local and remote. Another value: microservices integration and load testing. Microservices mocking, made powerful and easy (and shareable and reproducible). For load, answering two types of questions: a) how many RPS can this compute/memory config handle and b) given this RPS, what’s my floor for compute/memory config. Yet another value: robust analysis to minimize the time to solve. Easy, social visualization.

Delivering ease to some of our design partners is anything but easy. One particular partner needs an air gap solution. We’re currently in think/build mode on this piece. The rest of this blog has been redacted by our CEO. We love to share as much as we can, but we can’t divulge business secrets silly!

Will we cut the release in time for our 4PM meeting? Four open PRs need to be merged. We’ve cleared out schedules minus customer meetings. It’s all hands on deck.

Integration vs. Load

By Skylar |

I suppose we’re going to have to take a poll on this one, but if you had to rank the importance of functional testing vs. load/stress testing in the particular context of distributed app debugging by developers, which is more of a recurring pain for you? We’re all about providing recurring value to development teams and even their QA and SRE colleagues.

So far, every one of our design partners has identified simple, easy, powerful load testing of everything from APIs to collections of microservices as must-haves for finding and fixing cloud native app errors. About 50% have said the same for integration testing. Of course, the answers may vary based on personal preference, and the actual point of testing (i.e. inner vs outer dev loop).

Much of the work we need to do to get to shift left load testing includes functional testing as a prerequisite, so it’s a bit of an academic point, but we’re still curious. What do you think?

You Know You're in a Startup

By Skylar |

When your go-to-market meeting gets canceled because you’re too busy going to market, you know you’re in a startup.

Reactive vs. Proactive Use

By Skylar |

When you’re a new startup, identifying the primary use case is essential. At the start, you guess to get into the ballpark. And you iterate and refine based on customer feedback.

When we began Skyramp, we knew we wanted to help cloud native app developers become more efficient. We hypothesized that developer efficiency took a hit each time code came back from later on in the CI CD pipeline for debugging. We called this the “reactive” use case — if we offered an easier, faster way for developers to test APIs and microservices and get back to building at this particular moment we’d have our best shot at getting known and getting used.

And then a wonderful thing would happen. Skyramp is all about reusability, so once developer #1 solved for the first reactive case, when the same thing happened to developer #2, some of the work would already be done, making Skyramp even easier and faster to use. Eventually, tests covering more and more of the app would be explorable via Skyramp. The team would have the freedom to focus on any part of their cloud native app and ensure functional and load-based performance. But now, they could do it proactively — checking for potential errors earlier in the software design process. No additional labor required. We called this the proactive case. It’s part of our vision for shift left microservices testing.

Will it work? We’re going to find out.

Core Confidence

By Skylar |

There’s a reason we use the word “confidence” as Skyramp’s primary dev contribution. Not convenient, or easy, or powerful, or any other hyperbolic marketing gibberish. Just “confidence.” But why?

Because when it comes to API and microservices testing, and banking for that matter, a solution you can’t rely on may be worse than worthless. Deleterious. The point of knowledge often hinges on the accuracy of that knowledge. Let’s take the banking example first.

This is a tough week for us, and many of our brothers and sisters in startupland. SVB was a trusted partner in keeping the cash we fought so hard to obtain. Our lifeblood. We never worried about WHERE we put the money, only about using it wisely and getting more of it. Yeah, we were confident in the WHERE. And the rate at which that trust evaporated is, for most of us, hard to swallow.

Different players in the software development, integration, and delivery process (the whole CI CD Megillah), look for different things from testing cloud native apps. Because they care about different things. From the inner dev loop to the outer dev loop and beyond; from narrow integration tests to broader integration tests; from load tests to stress tests. If the results are either meaningless or inaccurate, they are less than worthless.

A few distinctions: no tests are ever going to catch every bug or error. And the truth is, devs in the inner loop care about some types of errors, but not others (say, environment-specific production errors). Same goes for QA, and all the way down the line to SRE. Part of confidence comes from the expectation that testing solutions answer the questions raised by a particular individual in a particular role. For Skyramp to give devs (and others) confidence when they develop, test, integrate, deploy, and ship code, we have to facilitate asking and answering the discrete questions of different types of users with different responsibilities. Skyramp tools have to be easily customizable, and shareable where appropriate, across a pretty diverse range of user.

But when devs do care about knowing something, asking a question, and testing, they and others expect the results of those tests to accurately answer the question asked. In science we call that high specificity (e.g. few to no false positives) AND high sensitivity (e.g. few to no false negatives). Anyone who had their nose swabbed in the early days of COVID knows the pain of low sensitivity and low specificity, empirically. The other half of dev confidence comes from accuracy — high testing sensitivity and specificity. Doesn’t have to be perfect, but perfection is the asymptotic goal for questions asked and answered.

In an upcoming blog we’ll talk more about what we mean by integration tests, specifically the narrow vs. broad distinction, the interplay with inner and outer dev loops, etc. Until then, chin up to our tech colleagues everywhere. With this latest FDIC news, I’m confident we’ll make it through this.

Container Descriptions, Helm Charts, and Hitting the Easy Button

By Skylar |

The key to developer-first, shift left adoption of modern microservices testing is ease of use. Throwaway tests — common today — are the opposite of easy. When we started Skyramp we knew that reproducibility was essential. Define once, use continually would make debugging easier during feature development, and much easier for the rest of the team down the road. They could benefit from the frictionless sharing of these cloud native application tests.

So this is a bit of an historical walk through of our thinking and building process. In the beginning, our primordial solution required the developer to create a few things: container descriptions (one for each of the services under test), a target description (the collection of services under test), and a test description (the desired test types and parameters). This has changed since then, but this is where we started.

For many of our design partners, this entry cost was an issue. We kept hearing the same gripe: I get test descriptions, but why go through the trouble to create container and target descriptions when much of this information already exists, for example in our helm charts?

Now, sometimes a partner’s helm charts are more monolithic than modular. Even massive. And the last thing a developer like this wants to do is to manually create subset charts, given the original is always changing and the source of truth. Wouldn’t it be great if he could simply specify the subsets of the charts he’d like to use for testing from the original? Could we solve this problem without container or target descriptions? Just test descriptions to guide Skyramp towards the best way to test a feature. And like that, our thinking changed.

Point is, when it comes to disrupting testing, let “easy” be your guide on your journey to shift left.

One Size Doesn't Fit All

By Skylar |

Building great dev tools, in part, comes from understanding that all devs aren’t the same. This impacts what we’re building at Skyramp in a variety of ways. We’ve alluded in past blogs that the pain points of testing APIs and microservices are relative to the skill set or simply the mindset of the dev. There is also a lot of variation among IDE preferences. Generally, we’ll start by meeting devs where they live statistically, and then make sure we have coverage for alternatives.

Case in point: one of our upcoming tools is designed to take the pain out of API and microservices mocking and imbue it with unique capabilities. We’re building a VSCode plugin for this tool. One of our devs commented that he’s tried to use many IDE tools including VSCode in its early days, and that he is way more productive with VIM than any other IDEs. To him, VSCode is better than VIM for beginners while VIM is better than VSCode when it comes to fast, efficient text editing. He argues that with know-how VIM can be set up with features equivalent or better than VSCode.

And he’s probably right, BUT … there are a LOT of VSCode users. We want Skyramp tools to meet them where they live, and that’s why we’re building a plugin.

One size does NOT fit all, and if you’re in the business of making life easier for devs — giving them more time to do what they prefer, i.e. build — you’ve got to offer tools granular and flexible enough to fit into their world, and not the other way around.

Five Easy Steps to Fix Avoidant Developer Behavior

By Skylar |

Can I share a little too much with you guys for a second? Sometimes, being around older people (older is relative of course) can make me feel a little anxious. Older parents for example. Or just casual acquaintances in their twilight years. And we all know why this is: they are a reminder of what we know is inevitably coming for us.

I could go on about how knowing nothing lasting forever imbues time with value. But I won’t. This is a software blog, after all. So what’s the point here?

We avoid things we don’t want to think about. And software developers aren’t any different. Consider our desire to test APIs and software. We want to build features. Sure, we unit test and make sure our code is solid. But even though we know a certain percentage of stuff is going to break and come back to us for debugging, we try not to think about it. Even in a magical world, if magical tests existed that let you ensure every microservice you built worked perfectly in the context of the larger app in the context of the larger production environment, you still might not run those tests. Don’t hate me, it’s just the way we’re built.

This is avoidant behavior, the dev edition. So what are some easy ways to change this and, as a result, catch mistakes earlier in the CI CD pipeline? I’m glad you asked:

  1. Make building tests and creating things like REST and gRPC mocks easier
  2. Make tests and mocks easy to share (so that they’re truly reproducible)
  3. Make test results and mock functionality more meaningful re: catching bugs with higher ROI
  4. Automate as much of it as possible so I don’t even notice
  5. Don’t make me spend time learning yet another CI tool, but do give me more free time to code

Hey, we can all dream can’t we?

A Team is a Team

By Skylar |

From the very beginning we knew that Skyramp was about small engineering teams working with Kubernetes clusters and other joys of modern software development. One to ten hands-on developers in a team, with a manager. In a startup there might be a single team. In a hyperscaler, too many to count, but each smaller unit still receptive to the same value proposition: giving each individual developer (and their manager) the confidence that the apps they’re building would function and perform as expected in the “wild” — the larger distributed app, under production-like conditions. Fewer integration errors, performance bugs, and regressions. Faster solutions. More time to build.

We still believe this. It’s fundamental to Skyramp’s design. But not all teams are equal. Some of our design partners work inside very large companies. And the infrastructure and security requirements at these bigcos can make things hard for us in our pursuit of delivering shift left cloud native application testing ease. I was on a Zoom today with Nithin, Sacheth (one of our awesome developers) and a Fortune 500 design partner watching commands fly in terminal as we tried to solve one of these unique deployment challenges.

We got it done on the Zoom, and left knowing we would keep surmounting these barriers on behalf of our customers. None of this is easy, but every interaction is an opportunity to learn. And what we learn here will make Skyramp that much easier for developers wherever they build their magic — even deep down the belly of large organizations.

To Merge or To Ship: That is the Question

By Skylar |

We’re still zeroing in on product/market fit. But it’s hard not to play with the language we might use to express Skyramp’s value to developers. We think it’s got something to do with confidence. Building and testing cloud native apps is a public affair and there is still a lot of unfamiliar ground and uncertainty. We want to give developers the perfect inner dev loop and CI tool — a safe space in which to experiment so they’re confident as they build that what they’re building will work, as expected, in the wild.

At first, we thought of “Code Confidently.” Nithin, our Co-Founder and CEO, suggested we needed another verb. “Ship Code Confidently.” That’s what we’ve got so far. But then Jacob raised the point that “shipping” was more oriented to DevOps testing, and the real danger comes in the merge. Yeah, merging has all the risk. I mean, you can try to ignore it, but it might come back to bite you. So, “Merge Confidently” may capture what we’re trying to do.

Other phrases pop up in conversation like “Get a grip on functional drift in the wild.” Adam liked it but Nithin wasn’t sure. Does this speak to developers? Let’s test that.

I am certain a lot of our thinking and language will change over the next few months. But I also know what won’t change: our commitment to shift left microservices testing to make it easier to ensure that what’s being built will work in production.

REST, gRPC, Thrift, Oh My!

By Skylar |

Very early on we were hungry for well-maintained, microservice-based applications that we could test against. When we looked at what was out there, we found Weavesocks for REST, and Online Boutique for gRPC. Thrift, unfortunately, was MIA. Besides the lack of Thrift, there were other challenges. Using two different applications made it hard to have consistent test cases across REST and gRPC.

We needed something better. We wanted an open-source sample microservices application that could be used for cloud native application development, API testing, and microservices testing across different standards–REST, gRPC, Thrift. Something extensible (e.g. adding GraphQL, eventually). While Weavesocks doesn’t look like it was being maintained, Google seems to be keeping up support for Online Boutique. So we forked Online Boutique and added REST and Thrift support in addition to gPRC.

We figured the Kubernetes engineering community could benefit from this project. So I’m here to share it with you, and to get your invaluable feedback.

Take a look.

Let me know what you think here. All feedback will be super appreciated!

Out of the Blue and You

By Skylar |

One of our design partners told us he’d love Skyramp to create “out of the blue” performance tests for whatever groups of microservices defined his application.

By “out of the blue” he meant this: he wanted to point Skyramp to any collection of his microservices — ready for API testing of endpoints (REST, gRPC, Thrift etc.) — and designed for any environment (private Kubernetes clusters, AWS, Azure, or GCP), and have Skyramp magically offer useful, configurable integration and performance tests including mock testing as needed. Optimized for the logic or intended production environment to deliver really useful results specific to those conditions. An essential CI tool democratizing shift left software test automation for CI CD tool users of varying skill levels.

These tests would visualize the inputs and outputs in a WYSIWYG UI so developers without testing expertise could understand what they’re testing. Low code or no code. And they’d allow those with more expertise and time to dig deeper into detailed software test mechanics. Then you’d share and tweak them to suit your very specific needs. Collaborative cloud native testing, done right.

Sounds like “out of the blue” and “generative AI” might have a lot in common? Maybe “out of the blue” is exactly what microservices testing needs to empower developers and QA :)

GitHub … for Marketers?

By Skylar |

Being developer-centric is more than just a theory at Skyramp. Of course, most of our team are developers. But everyone else is busy getting to know our cloud native customers. Finding ways to make testing APIs and microservices easier for everyone so that software test automation doesn’t send people into safe spaces. And the best way to do that is for every single one of us to use some of the dev inner loop and CI tools that developers use.

Ask Adam, our Head of Marketing. When Seema, our Head of Product, suggested he create marketing content in GitHub, his Zoom face said it all. A few weeks later, the pull requests for copy updates are no longer so surprising. It’s one of the small ways we stay developer-focused.

The next step was to get Adam to use Skyramp to automagically stand up a Kubernetes cluster on his local machine, deploy Target services in REST, gRPC, and Thrift, and run performance testing with mock APIs and endpoints. If Adam can do it, we know we’ve checked the box on simplicity (sorry Adam)!

Now even our marketers live part-time on terminal, updating their Golang and trying out each new version of Skyramp.

Because if we can give marketers like Adam this kind of confidence, imagine what we can do for you.

Hello Distributed World

By Skylar |

If you asked Jacob, our head of Platform, he’d say we started Skyramp to help developers deal with the sh#tstorm of distributed development.

Colorful, but not wrong. There are lots of new complexities slowing developers down. And lots of recurring worries. Like merging code and trying not to think about whether it’s going to create downstream functional or performance issues in the greater application.

We want to give distributed app developers incredible confidence — every time they merge. And when code does come back for debugging, we want to make it dead simple to run integration, performance, and load tests — no expertise or much effort required. We want to help developers find and fix functional and performance errors and get back to building ASAP.

Confidence comes from tests that accurately reflect production. And developer-first means almost magical support for any language or environment, and the ability to run tests with minimal effort — even for really big apps — sometimes right on a developer’s resource-limited local machine.

We built Skyramp to help developers get a grip on how their code works in the wild, even as they code. We’re not there yet but we’re deep in build mode. And we believe that the secret to our success will be a maniacal focus on developer confidence — starting with our awesome collection of super-dedicated design partners.

This blog is our journey. You’re invited.