SkyU Console

Read about what you can do with our platform

SkyU transforms the way enterprises build, share, and run cloud-native applications.

The ability to visualise, group, and assign ownership of microservices enhances organisation and accountability. The restriction of one microservice per team promotes clarity in responsibility.

Microservices management

Native kubernetes support

Multi cluster multi cloud support

This feature take a blueprint approach with a high-level overview of infrastructure. This helps in understanding system architecture and dependencies. It is crucial for strategic planning and troubleshooting.

Architecture visualisation

Application and workloads

The platform’s dashboard offer deep insights into environment specifics like cluster allocation and release schedules is essential for effective environment management.

Environment dashboards

SkyU uses Terraform for infrastructure as code (IaC) to powerfully ensure consistency and repeatability in environment setups. Use features like single-click launches and drift detection to streamline environment management and maintain stability.

Infrastructure provisioning and management

Manage multiple environments

Environment management

Release Scheduling and History functionalities enhances the control and traceability of releases, which is vital for maintaining high-quality deployments. SkyU’s hyper-quick rollbacks is crucial for minimising downtime and maintaining service quality.

Release orchestration

Integrating CI tools and automating artifact promotion are important for streamlining the CI/CD pipeline. SkyU platform uses robust delivery pipelines are key for managing infrastructure changes, ensuring that each step is executed correctly and efficiently.

CI/CD and automation

The platform’s combination of RBAC and SSO creates a defense-in-depth strategy, clear identity management and audit trail. These are fundamental for security and compliance standards. The SSO integration simplifies the user experience and enhances overall security.

User & account management

Take advantage of our dynamic configuration and make changes to credentials in real-time. Maintain flexibility and manage all infrastructure using our systematic and automated approach to systems configuration.

Configuration management

Comprehensive dashboards add an extra layer of transparency and control using tools for log aggregation and more. Get proactive monitoring and seamless incident management. The AI-powered assistant for alerts and notifications significantly improve response times and solution accuracy.

Observability

CI/CD out of the box

Centralised configuration

Release and configuration management

Our internal developer platform is designed to streamline the daily tasks of a DevOps engineer

“code-to-commit”

pathway

For many organizations, the question has shifted from "Should we build a platform?" to "How do we start?" The answer lies in embracing the concept of a Minimum Viable Platform (MVP). Our MVP approach allows you to start small, move swiftly, and remain cost-effective.

Soar through releases with a platform that establishes clear ownership and simplifies the

Browse our rich ecosystem of ready-to-use plugins

Ascend to new heights with SkyU!

Platform

This article is aimed at test analysts and other stakeholders who engage in software quality assurance in a managerial capacity. The article discusses some of the unique challenges and opportunities associated with testing an Internal Developer Platform product like SkyU and shares a few reasons why buying one is better than building one in-house.

The International Software Testing Qualifications Board defines testing as “a set of activities to discover defects and evaluate the quality of software artifacts” [1]. Typical software testing activities include activities such as analysing requirements, designing test cases, executing test cases, and comparing expected results with the actual results to identify defects. Based on criteria such as the product architecture, technologies, and business requirements, these testing activities' effort, complexity, and risk tolerance can vary greatly.

To understand this idea, imagine how a product team developing a food order management system for the internal use of an organization might settle for simpler less effortful solutions with higher risks related to the quality of their product compared to a mission-critical food order management system that is built to cater to an entire nation which would demand a much lower tolerance of risk at higher complexity and effort. SkyU, as a PaaS product open to organizations with product development aspirations on both ends of this spectrum, the SkyU QA team has to ensure the product meets the quality assurance expectations of both mission critical software projects as well as software projects catering to trivial business needs.

Challenges and Opportunities Testers of Platform Engineering Products Can Expect

The challenges of testing a platform engineering product like SkyU can be categorized into,

Challenges that arise from the large number of 3rd party services and technologies that need to be bundled in.

Challenges associated with conducting manual and automated end-to-end testing.

Though internal developer platforms are built specifically to meet an organization's needs, with an OOTB platform engineering product like SkyU, you can't offer a narrow set of features and configurations. This results in the need to support a large number of third party services such as Github Actions, Docker Hub, AWS EKS, and ChatGPT, as well as technologies like Docker, Kubernetes, Helm, and Kustomize. These services and technologies need to work seamlessly across the various layers that make up the product. From a quality assurance perspective, the interconnectedness of these components increases testing activities.

When it comes time to design test cases, a tester will analyze the functionality offered by these 3rd party services and identify how it relates to the functionality offered to the end user. The tester will then employ test design techniques such as 

pairwise testing, decision tables, state transfer diagrams,

 to design the optimal number of test cases to cover the feature. A pain point unique to IDP products to this end is the identification of all the expected results for a given test case.

For example, if a new Cloud CI service is being introduced as a feature (say BitBucket), when creating test cases, a tester may need to identify the expected results to look for in the GUI under the ‘Developer Control Plan’, ‘Integration’, and ‘Delivery Plane’ and the ‘Monitoring Plane sections’. The tester will then need to identify any expected results related to the database that is only accessible through the API layer. Finally, the tester will need to look at the expected results that need to be accessed in the 3rd party service, such as the commit history or pipeline information.

Another pain point associated with testing IDP products is the complexity involved in creating end-to-end test automation scripts. The automation scripts require adaptation to interface across multiple services, architectures, and interface types while maintaining synchronization between the scripts and the system under test. This is to ensure a reliable test execution.

However, it's not all pain for the tester, as Churchill is known to have once said “A pessimist sees the difficulty in every opportunity; an optimist sees the opportunity in every difficulty”, the very challenges associated with testing an IDP can be the strengths that can propel the careers of testers of an IDP product past that of their peers in this day and age of AI prompt based software engineering. As testers work their way into the innards of the product, they will get opportunities to up their DevOps skills and knowledge which is still highly sought after. Coupled with their experience in quality assurance, they will be able to uniquely position themselves in the job market.

The benefit of going with platform engineering products on an organisation's software quality assurance function

One of the main selling points of going with a platform engineering product like SkyU, as opposed to building a platform in-house, is the lowered cost of ownership. One reason why this is a valid point is the quality assurance-related effort that goes into the delivery of an IDP product. Organisations can piggyback on the process of testing which the vendor has already put into the product. They can benefit from the feedback cycle from other users who’ve used it and the community as a whole.

Ideally, the IDP product vendor should ensure the quality of the three lower levels of the test pyramid. That is the component level testing through developer unit tests; integration level testing through component integration testing and API testing and system level testing through end-to-end testing. Meaning, organisations can focus on the different acceptance tests such as operational acceptance, regulatory acceptance, and user acceptance. All of this will lead to a cheaper and faster ownership of the IDP.

In summary, this post aimed to provide an overview of the challenges and opportunities that IDP product testers may encounter. It also highlighted the benefits organizations can gain by purchasing an IDP rather than building one in-house, particularly in terms of the advantages it offers to the quality assurance function and the impact on the bottom line.

https://www.istqb.org/certifications/certified-tester-foundation-level

https://qacraft.com/levels-of-testing-in-software-testing

Testing an Internal Developer Platform: Why Out-of-the-Box Solutions Make Sense

In the fast-paced world of Formula 1, speed and precision are everything - every millisecond counts and a tiny misstep can mean missing out on the podium. It’s a lot like platform engineering, where the goal is to deliver software quickly and efficiently while juggling complex systems. Just as F1 teams fine-tune every detail, from engine performance to pit stops, platform engineers analyse data and make split-second decisions to stay ahead. The bottom line? In both, being “slow and steady” just doesn’t cut it. If you want to win, you’ve got to prioritise speed and adaptability.

Platform engineering, much like F1, operates in a high-pressure, high-speed environment. The demand for continuous integration, continuous deployment (CI/CD), and fast iteration cycles mean that platform teams need to design systems that are not only stable but also capable of supporting rapid changes and scaling without delay. In modern businesses, the ability to release software updates quickly and reliably is crucial to staying competitive.

Platform engineers must continuously improve infrastructure, deployment pipelines, and observability tools to keep everything running at top speed. This has gotten increasingly complex as the cloud-native computing landscape is a lot to take in!

Platform teams need to choose the right tooling and figure out how best to create toolchains that work. Source: 

Why “Slow and Steady” Fails in Platform Engineering

Platform engineers must keep up with the fast-moving technological landscape. With rapid innovations in cloud computing, DevOps practices, and container orchestration, moving slowly risks falling behind. Those who aren’t constantly improving their platforms may be overtaken by competitors with more agile, modern systems.

They need to solve problems in real-time. Quick responses are essential, whether it's handling unexpected traffic spikes, mitigating security vulnerabilities, or fixing failed deployments. Slow responses in either environment can lead to catastrophic results, whether that’s a car retiring from the race or an outage that costs a company millions in lost revenue.

Every experience offers new lessons, and teams must adjust accordingly. Platform engineering operates under the ethos of 

. Static systems that evolve slowly will eventually struggle under new demands. Continuous delivery pipelines, automated testing, and infrastructure as code help engineers maintain the pace needed to deliver value quickly and consistently.

The most effective systems are those optimised for high performance while maintaining control. Platform engineers strive to create systems that can handle high traffic, scale efficiently, and remain reliable under heavy workloads. While a cautious approach may reduce risks, it can also limit opportunities for innovation.

In all these aspects, just as in racing, the key to staying competitive lies in agility, quick decision-making, and a commitment to continuous improvement.

A well-designed technology platform can make a huge difference here - not just for the Platform team but for the entire “pit crew” of your organisation (Infra, Ops, Security, Information Systems, Site Reliability and more). The concept of an internal developer platform is not new. It emerged as a modern way to run engineering teams with elite teams self-building IDPs for around 5 years prior (for example, Spotify, Airbnb).

Build vs Buy: Internal Developer Platforms in the Race for Speed

Platform engineering teams face a critical decision now: should they build an internal developer platform (IDP) from scratch, or should they buy an off-the-shelf solution? Platform engineers must assess which will get them across the finish line faster.

For many teams, the best approach is often a 

. They may start with a bought solution that covers their core needs and then customise or extend it where necessary, combining the best of both worlds.

SkyU: A Solution to Accelerate Your Platform Engineering

 option for an internal developer platform, SkyU is a powerful solution designed to meet the demands of modern platform engineering. SkyU is built to help teams streamline their development processes, enabling faster software delivery while maintaining the stability and scalability needed to compete in today’s fast-paced environment.

With SkyU, platform engineering teams can:

 SkyU's pre-built platform ensures you can get started quickly, reducing the friction and delays associated with building an IDP from scratch.

 By providing streamlined workflows and automation tools, SkyU helps your engineering teams focus on innovation rather than infrastructure management.

 As your organisation grows, the platform scales effortlessly, ensuring that your internal systems are always ready to handle increasing demands.

The platform offers continuous updates and support, allowing platform engineers to focus on delivering value rather than worrying about maintaining the platform itself.

Choosing SkyU lets you bypass all of the complexities and time constraints of building a custom platform. At the same time, it modernises your software delivery, accelerating and transforming your customer experience entirely.

In F1, the winner isn’t the one who drives the safest, but the one who drives the fastest while making the fewest mistakes. In platform engineering, the same holds: speed, agility, and continuous improvement are the keys to success.

So, buckle up - slow and steady won’t win this race. 

F1, DevOps & Platform Engineering: Why Slow and Steady Won’t Win the Race

In platform engineering, two common metaphors illustrate the impact of design choices: 

. Both represent an opinionated approach to platform design, but their outcomes are strikingly different. This article explores the delicate balance between structure and flexibility, the importance of avoiding traps, and how the decision between 

Golden Path: Guidance Without Restriction

 is the ideal many platform teams aspire to create—a curated experience that provides developers with a smooth, efficient, and secure route to deliver value. By using standardised workflows, approved tooling, and best practices baked into the platform, developers enjoy:

: Reduced complexity for new team members.

: Fewer distractions from operational tasks.

: Compliance and reliability are built into the workflow.

. Developers can choose to diverge from the opinionated path when their use case demands innovation or customisation, enabling them to tackle unique challenges without hindrance.

Golden Cage: Over-Optimisation Gone Wrong

, on the other hand, results when platforms are designed with too many constraints, turning guidance into restrictions. Developers might find themselves stuck in rigid workflows that don't cater to their unique needs or the evolving demands of the business. This happens due to:

: Tools and processes that cannot evolve with technology.

: Developers spend more time bypassing the system than delivering value.

The Golden Cage stifles innovation, frustrates teams, and ultimately slows down the organisation.

Flexibility is the antidote to the Golden Cage. A great platform balances opinionated guidance with the freedom to adapt. Here's why flexibility should be at the core of any platform:

: Teams can innovate without being locked into a single way of working.

: Platforms can grow with the organisation, integrating new tools and workflows as needed.

: Flexible systems adapt to change, preventing obsolescence.

Flexibility doesn't mean chaos; it means offering curated paths with the option to step off-road when necessary.

 your platform profoundly affects whether you achieve a Golden Path or fall into a Golden Cage. Each approach has its merits and trade-offs, and the right choice depends on your organisational goals, resources, and expertise.

Building your platform offers the ultimate in customisation. With tools like Spotify's Backstage, organisations can create a fully tailored experience. However, building is not without challenges:

: Building an internal platform requires a significant upfront commitment in terms of time, money, and skilled personnel.

: A dedicated platform engineering team is essential for development, iteration, and maintenance.

: Beyond the initial build, ongoing upkeep, scaling, and adapting to new technologies demand continuous effort.

While building offers complete control, the cost in resources and operational burden can be prohibitive for teams without extensive platform engineering expertise.

Buying a platform offers an immediate return on investment (ROI), especially for teams that need to hit the ground running. Solutions designed for internal developer platforms (IDPs) deliver:

: Platforms like SkyU provide workflows, integrations, and compliance out of the box, minimising the time to value.

: Prebuilt platforms reduce the need for large platform engineering teams, freeing resources to focus on business outcomes.

: Vendors often provide ongoing updates and support, ensuring the platform stays relevant as your organisation grows.

Buying a platform lets you focus on delivering software rather than building infrastructure. It strikes a balance between the Golden Path’s efficiency and the flexibility needed to avoid the Golden Cage.

In platform engineering, the difference between a Golden Path and a Golden Cage comes down to design choices that prioritise flexibility and developer empowerment. Whether you choose to build or buy, the goal should be the same: to create a platform that enables developers to deliver value efficiently while preserving the freedom to innovate.

For teams ready to invest deeply in customisation, building a platform may offer unmatched control—but it comes at a cost. For those seeking immediate productivity gains and long-term adaptability, buying a solution offers an easier path to success. Platforms like SkyU exemplify this approach, enabling teams to embrace the benefits of the Golden Path without the risk of becoming trapped in a Golden Cage.

Golden Path vs. Golden Cage in Platform Engineering: Why Flexibility Matters

Blue/Green deployment strategies allow you to minimize downtime and reduce risk during application updates. In this article, I will walk you through setting up an Amazon ECS (Elastic Container Service) Service with Blue/Green deployment using AWS CodeDeploy.

This approach ensures that your service remains available while rolling out new application versions. AWS CodeDeploy enables you to deploy new versions of your application without causing downtime. It allows for a gradual shift of traffic from the old version (blue) to the new version (green).

Here is the Overview of a Blue-green deployment:

In the architecture shown above, we use several key AWS services to manage the automated blue-green deployment:

 manages the blue-green deployment process.

 to route traffic between the old and new versions.

 on the Amazon ECS compute platform assigns listeners to direct traffic to the updated ECS application and uses two target groups during the deployment. CodeDeploy also manages rollbacks by redirecting traffic from the new task set back to the original task set if needed.

The following sequence diagram illustrates the key steps in updating Amazon ECS services.

Step 1: Setting Up AWS Identity and Access Management (IAM) Service Roles

To kick off the process, it's essential to set up the required permissions using IAM roles. You will need to create roles for both the ECS task execution and the CodeDeploy service. These roles will allow AWS services to interact with each other securely.

: This role allows ECS to pull container images and publish logs to Amazon CloudWatch.

: This role gives AWS CodeDeploy the necessary permissions to manage your ECS services during a Blue/Green deployment.

, and then select the required services (ECS, CodeDeploy).

Use the AWS Managed PolicyAWSCodeDeployRoleForECS for the IAM role.

Step 2: Creating the Application Load Balancer (ALB)

An Application Load Balancer (ALB) distributes incoming traffic across multiple targets, such as Amazon ECS tasks in this case. The ALB plays a crucial role in Blue/Green deployment by directing traffic between the old (blue) and new (green) versions.

3. Configure the listener to forward HTTP (port 80) or HTTPS (port 443) requests.

4. Choose at least two Availability Zones to ensure high availability.

5. Create a new target group(Target Group 1 — Blue) or use an existing one to register your Blue Version ECS tasks.

The ALB will handle routing during deployment, gradually shifting traffic from the blue version to the green one.

Step 3: Creating the Amazon ECS Task Definition

Next, create an ECS task definition, which is a blueprint describing the containers to run as part of your ECS service. This step involves defining the Docker image, CPU, memory requirements, and networking configuration.

4. Define the container configuration, including:

Container image (e.g., from Amazon ECR or Docker Hub)

Environment variables and logging settings.

For testing purposes, you can use the Nginx Docker image with an HTML file to identify the Blue/Green version.

Let’s use the Docker image sachithram/nginx-blue:latest for the blue version. To perform the blue/green deployment, create a new revision of the task definition, updating only the image tag sachithram/nginx-green:latest for the green version.

5. Once the task definition and revision are created, this configuration will be used to launch containers during the Blue/Green deployment process.

Step 4: Creating the Amazon ECS Service with Blue/Green Deployments

With your task definition ready, the next step is to create an ECS service that uses 

. AWS CodeDeploy will manage the process, ensuring the new version is tested before routing traffic to it fully.

Steps to create the ECS service with Blue/Green deployment:

1. Open the Amazon ECS Console: Go to the 

 and choose the ECS cluster where you want to deploy your service. Let's use a Fargate Type ECS Cluster.

Blue/Green deployment (powered by CodeDeploy)

all tasks in the service are updated simultaneously

. This deployment method quickly replaces the old (blue) version of the tasks with the new (green) version without any gradual traffic shift.

 where your ECS cluster runs. Ensure the subnets you select are accessible to the 

, choose two subnets in different availability zones to ensure high availability.

 for the ECS tasks. Ensure that the security group allows communication between the ECS tasks and the ALB. Add any necessary inbound/outbound rules, such as allowing 

 if your application listens on that port.

 should allow inbound traffic from the internet. The 

 should restrict inbound traffic only to allow connections from the 

, ensuring that the containers are only accessible through the load balancer.

Next, you’ll need to associate your ECS tasks with the load balancer listeners:

 (or any port that the green deployment will be using for testing).

Ensure that the ALB listeners and security groups are set up to allow traffic from the ECS service.

 Select the target group you created earlier when setting up the ALB. This will be the 

 If you haven’t created a second target group for the green environment, create it here and associate it with your ECS service.

When you create the service you can go to the load balancer URL and you will see the blue version can be accessed from the load balancer.

AWS CodeDeploy will manage traffic shifting between the 

It will perform health checks on the green environment before switching all traffic.

Step 5: Verifying the Amazon ECS Blue/Green Deployment

Finally, you need to verify that the deployment was successful and the new environment is running as expected. AWS CodeDeploy allows you to perform gradual traffic shifting, monitor deployment health, and perform rollbacks if necessary.

, you will see your ongoing ECS Blue/Green deployment.

 to ensure the green environment receives traffic successfully.

4. Once the new version is stable and working, CodeDeploy will shift all traffic from blue to green.

Update the ECS service with the new Green Task Revision. Once updated, navigate to the AWS CodeDeploy Dashboard, where you will see a new deployment has been triggered.

Implementing Blue/Green Deployments with Amazon ECS and AWS CodeDeploy

In the evolving world of software development, efficiency and speed are paramount. GitOps, a paradigm shift within the DevOps community, leverages Git as the backbone for automating and optimizing the software deployment lifecycle. This guide unpacks the essential strategies and benefits of integrating GitOps into your DevOps practices.

GitOps represents a set of best practices that use Git as the single source of truth for managing cloud-native application configurations and infrastructure deployments. This means everything we manage, including application manifests, configurations, secrets, and infrastructure, is maintained through Git. This approach ensures consistency and traceability for all aspects of the system management, facilitating a more streamlined and secure workflow in cloud-native environments. By adhering to these practices, teams can improve their operational efficiency and maintain higher standards of code and configuration management.

Declarative System Description: The entire system is articulated in a declarative manner, meaning its configuration is specified rather than the steps to achieve it. This approach allows for clearer understanding and more predictable outcomes.

Version-controlled Desired State: The preferred state of the system is systematically versioned within Git. This ensures historical tracking, facilitates rollbacks, and enhances transparency across the system's lifecycle.

Automated State Synchronization: The system automatically retrieves its state from Git and aligns it with the current state of the platform. This automation helps maintain consistency and reduces manual errors during deployment.

Continuous State Monitoring and Reconciliation: The actual state of the system is continuously monitored against the desired state stored in Git. Efforts are consistently made to reconcile any discrepancies, thereby ensuring the system remains stable and secure.

At the heart of the GitOps framework is the GitOps agent, a pivotal component that ensures seamless deployment and constant synchronization between the Git repository and the live environment. Acting as an essential intermediary, the agent guarantees that the operational state mirrors the intended configurations stored in Git, thereby encapsulating the collaborative essence of DevOps and streamlining the deployment lifecycle.

Integrating GitOps into DevOps practices significantly boosts operational efficiency and deployment speed, fundamentally transforming the software development lifecycle. Let's discuss the impact of GitOps on DevOps efficiency through its key benefits and a Kubernetes deployment use case as an example.

Automated Deployments: GitOps automates the deployment process, reducing manual efforts and minimizing human errors. This leads to more reliable and consistent deployments.

Collaboration and Transparency: Using Git as the single source of truth enhances collaboration and transparency. It provides a unified view of the system's state and changes, making code reviews and approvals more efficient.

Security and Compliance: GitOps utilizes Git's features to enforce security policies and compliance standards. Changes undergo vetting and approval processes, improving the security posture of the deployment pipeline.

Continuous Optimization: Continuous monitoring and optimization of deployments ensure systems remain efficient and aligned with intended configurations.

The provided image illustrates a streamlined process for deploying applications in a cloud-native environment using GitOps principles:

A developer commits changes to the application code in the Code Repository.

The Continuous Integration (CI) pipeline builds a Docker image from the code and pushes it to the Container Registry.

The CI pipeline updates the GitOps Repository with the new image version or configuration changes.

The GitOps Agent detects the updates, synchronizes changes, and automatically applies them to the Kubernetes Cluster.

The application is deployed to the Kubernetes Cluster, where it is ready for use.

This use case highlights GitOps' role in simplifying and securing deployments, ensuring predictability, reversibility, and alignment with operational goals. By combining GitOps and DevOps, teams can deliver software faster, with higher quality, in a more manageable, and secure manner, significantly improving operational efficiency and system reliability.

Maximizing DevOps Efficiency by Streamlining Deployments with GitOps

TLDR: We launched automated release management for SkyU.io! Share, discover, and implement the feature built to automate your experience as a release manager. Learn how, why, and what to try first, below.

Hey all, Heshan here. Here’s a little about the "Project Releases" feature the team has been working on.

If you've ever shipped software, you know the drill. Release days can be absolute nightmares. Last-minute fixes, versioning confusion, and that awful moment when something goes wrong in production... it's hectic!

But with "Project Releases," we're finally tackling this head-on.

Streamlined releases, from start to finish:

We advocate for a platform-as-a-product mindset. It helps us navigate "complexity quicksand" while proving value quickly.

Ascend to new heights with SkyU!

Git version control

Microservices management

Architecture visualisation

Environment management

Release and configuration management

Read about what you can do with our platform

Compliance, Security, and Policies Associated with a Public Sector Enterprise

DORA Metrics and Engineering Excellence, Achieving Faster Releases

Maximizing DevOps efficiency by streamlining deployments with GitOps

Subscribe for the Beta Release