Logo of Osakidetza, the Basque Health Service, featuring a modern design with clouds and abstract elements.

256_cta-background.webp

384_cta-background.webp

640_cta-background.webp

750_cta-background.webp

828_cta-background.webp

thumbnail_cta-background.webp

osakidetza-logo

Daar hebben wij de oplossing voor

Wilt u efficiënter werken? 

Abstract digital background featuring interconnected lines and glowing points in shades of blue and green.

1080_background.webp

1200_background.webp

256_background.webp

384_background.webp

640_background.webp

750_background.webp

828_background.webp

thumbnail_background.webp

atmosphere-water-sky-azure-electricity-astronomical-object-slope-electric-blue

Logo of Zen Software in white on a transparent background.

1080_zen-logo-white.webp

1200_zen-logo-white.webp

256_zen-logo-white.webp

384_zen-logo-white.webp

640_zen-logo-white.webp

750_zen-logo-white.webp

828_zen-logo-white.webp

thumbnail_zen-logo-white.webp

zen-logo-white.webp

ZEN Software

1080_zen-logo-black.webp

1200_zen-logo-black.webp

256_zen-logo-black.webp

384_zen-logo-black.webp

640_zen-logo-black.webp

750_zen-logo-black.webp

828_zen-logo-black.webp

thumbnail_zen-logo-black.webp

západoslovenská energetika-logo

Project Reinforcement

New Software Project / Modernisation

Tech Consultancy

Cloud Consultancy

What We Do

Cases

About us

News

Contact

Success! You`ve been added to our email list.

Subscribe to our email list and we will keep you updated on DevOps and ZEN Software News and Trends

Subscribe to ZEN Software's  newsletter

Remote Development in the Cloud

Remote development has become increasingly popular in recent years. It allows developers to take advantage of powerful cloud computing resources and be available everywhere using a managed central configuration. There are several cloud-based solutions available for remote development, including Google Cloud Workstations, AWS Code Catalyst, and traditional virtual machines (VMs). In this article, we will compare the costs and advantages of each option.

Remote development has become increasingly popular in recent years. It allows developers to take advantage of powerful cloud computing resources and be available everywhere using a managed central configuration. There are several cloud-based solutions available for remote development, including **Google Cloud Workstations, AWS Code Catalyst**, and traditional virtual machines (**VMs**). In this article, we will compare the costs and advantages of each option.

Google Cloud Workstations is a cloud-based development environment that provides a fully managed developing environment in the cloud, including popular tools like the JetBrains IDEs such as IntelliJ Ultimate, IntelliJ IDEA and PyCharm. 

It is designed to offer a high-performance environment that can handle even the most demanding development tasks.  Google Cloud Workstations come with a large amount of customization and control options that can help manage costs and productivity. 

AWS Code Catalyst is a cloud-based development environment provided by Amazon Web Services (AWS). It is designed to help developers collaborate on code, automate workflows, and manage projects in the cloud. AWS Code Catalyst provides a wide range of tools and services that can help developers build, test, and deploy code. 

Using a virtual machine (VM) hosted in either Google Cloud Platform (GCP) or Amazon Web Services (AWS) can be a great option for developers who need a flexible and scalable development environment. However, these basic VM options don’t come with pre-installed developer tools and other useful components and tools. This downside is compensated by the fact that they are generally cheaper than the Cloud workstations or CodeCatalyst options and can be made even cheaper when using the spot prices and discounts.

To compare the pricing, I have added the following table. In this table the pricing is listed for a machine of 4 vCPUs and 16GB of memory. For each option, the hourly cost and the monthly cost is listed. 

above

One way of connecting to one of the services is through JetBrains Gateway; here, I will go through the steps for AWS CodeCatalyst. The use of JetBrains Gateway is quite easy, just log in using the big login button and follow the steps shown on the screen. These steps include signing in to your AWS builder account and allowing JetBrains Gateway access to some of your information. After Signing in, you will see the following screen, which shows your projects and dev environments. 

Here you can also create new dev environments through the “Create Dev Environment” button. Clicking this button shows you the same options you would have in the web interface. After configuring just click the button to create and a popup should show telling you its working on it. Once its done it opens the newly created dev environment. 

To connect to your remote development environment, you just simply click on the environment you want to boot. This process can take a few minutes and goes through multiple steps.

Once the dev environment is ready, it will open the IDE just like it would do if you were using it locally. The only difference is that there is an extra menu at the top left showing the status and latency of the machine. Clicking on this menu opens the memory, storage and CPU usage. 

And Done! You are ready to use your remote developing environment!

When it comes to remote development, there are several options available, each with its own advantages and costs. Google Cloud Workstations and AWS CodeCatalyst provide fully managed and ready-to-use development environments with a wide range of tools and services. They are designed for large teams and enterprise-level projects, but their costs can be significant. 

Normal VMs provide a customizable and cost-effective solution for small teams or individual developers but don’t have some of the ease-of-use features that Google Cloud Workstation or AWS CodeCatalyst has. 

One thing to note is that AWS Code Catalyst is significantly cheaper than most other options. However the limited available zones might make the working experience significantly worse and thus an alternative service could be of interest to use even though it might be more expensive. 

Ultimately, the choice of which option to use depends on the specific needs of the project, the size of the team, and the available budget.

This is how you prevent nightmare cloud bills: API Quotas and Budget Alerts

Sleepless nights over spiking cloud cost? we have an open source and gratis solution!
In this article, we'll delve into setting up a hackathon using Google Cloud's unique Generative AI and Machine Learning capabilities. We’ll do this in a safe an secure manner by employing the powers of Budget Alerts and API Quotas.

Sleepless nights over spiking cloud cost? we have an open source and gratis solution!

In this article, we'll delve into setting up a hackathon using Google Cloud's unique Generative AI and Machine Learning capabilities. We’ll do this in a safe an secure manner by employing the powers of Budget Alerts and API Quotas. Using this easy solution you’ll be able to

:heavy_check_mark: Focus on innovation and groundbreaking new features    
:heavy_check_mark: Hyper speed of development   
:heavy_check_mark: All the right resources at your fingertips   
   
   
And prevent the nasty bits like:   

:x: Spending thousands of dollars on Google Cloud for 24 hours of usage   
:x: Training ML models on massive unfiltered data sets   
:x: Inadvertently launching a DDOS attack and funding the receiving side of it    

Try it out: a Hackathon using secured sandbox projects

Hackathons are dynamic events where teams come together to create innovative projects or features within a limited timeframe. However, amidst the excitement of ideation and development, there's a looming concern for project organizers: the potential for runaway [cloud costs](/what-we-do/solutions/zen-cloud-landing-zone). 

But why is this so important? While GCP offers a plethora of powerful services and resources, it's easy for enthusiastic teams to unintentionally rack up expenses, especially when experimenting with advanced features. To avoid such budgetary nightmares and ensure a smooth hackathon experience, we'll explore the intricate details of configuring budget alerts and dealing with service quotas through Terraform. 

Along the way, we'll address the challenges faced when integrating service quotas with Terraform, shedding light on the cumbersome aspects of this process and providing insights into how to navigate them effectively. By the end of this article, you'll be well-equipped to create a cost-effective and secure GCP environment for your hackathon, empowering teams to innovate without the fear of unexpected financial consequences.

Creating Google Cloud Projects and Roles (Manually?)

Manually creating multiple projects in Google Cloud Platform (GCP), especially when they require distinct user access and roles, is time-consuming and prone to human error. This process can be particularly challenging when setting up projects for multiple hackathon teams. To overcome these issues, using infrastructure as code (IaC) tools like Terraform can simplify project provisioning, user management, and role assignments. This approach ensures consistency, scalability, and reduces administrative overhead. ZENsoftware offers an open-source project that includes essential features such as budget alerts, user roles, and service quotas to address these challenges. The GitHub -[ zensoftwarenl/google-cloud-hackathon](https://github.com/zensoftwarenl/google-cloud-hackathon) project. 

Setting up quotas for Google Cloud Platform (GCP) resources is an essential step in managing your cloud infrastructure efficiently. In an ideal world, this process should be straightforward and hassle-free, but in reality, it is anything but that. While the initial expectation is that setting quotas should be easy, considering it is a vital part of cost management, it turned out to be unexpectedly challenging when using Terraform to handle the task. These difficulties stem from a combination of factors, including inadequate documentation, confusing terminology, a lack of clarity about unit formats, and the inherently manual nature of the process. We'll explore these challenges in detail, shedding light on the complexities that can arise when working with GCP quotas through Terraform.

Firstly, the documentation can be somewhat insufficient and disjointed. GCP and Terraform tend to use different terminology when referring to quotas and limits. While Terraform consistently employs the term "limit," GCP labels them as "units." This disparity in terminology can cause confusion, making it challenging to align Terraform code with GCP's quota management.

Furthermore, the format of the “unit” can be cryptic. GCP introduces various "unit" formats, such as ```/d/project``` in one context and ```/min/project/user``` in another (other examples include ```/project/region```, ```/min/project```) . Deciphering these variations and comprehending which format applies to a specific quota can become a source of bewilderment. 


Moreover, understanding the precise unit format for a particular quota is not readily accessible through documentation. This vital information often remains hidden, requiring users to delve into GCP's command-line tools or web interfaces to unearth the specifics. For example, the GCP documentation states the “unit” format requires the values to be formatted with ```{}``` in the unit, but in Terraform using these brackets in the unit will not work. Even when inspecting the requests sent out by the [console.cloud.google.com](https://console.cloud.google.com) the request unit is written with ```{}``` while in Terraform this will absolutely not work. 

In summary, while Terraform excels in automating various aspects of infrastructure management, the intricacies surrounding GCP quota management remain a challenging and less streamlined facet of cloud resource provisioning. Navigating unclear documentation, inconsistent terminology, and non-standardized unit formats can transform what should be a straightforward procedure into a formidable task, highlighting the need for improvements in this area to enhance user efficiency and experience.

To demystify the complex process of setting up GCP quotas using Terraform, we embarked on a journey of exploration, uncovering the intricate details of each quota. Here's how we navigated through the labyrinth of quota management. 

Our journey began by inspecting the outgoing requests generated by the GCP Console. This exercise allowed us to peer into the internal format and structure that GCP used for managing quotas. However the “fun” part is that the API used by Terraform is different from the one used by the console. This resulted in the format not being correct and ended up being a useless exercise. 

Moving on, we turned to the user interface (UI) for further insights. Enabling a specific service within the GCP Console and listing its associated quotas in the UI revealed not only the quota Metric but also started to unveil the underlying format for the unit. Here the documentation inconsistency comes back again, in this UI the value for the unit is called “Limit name” and is not in the format of slashes but instead is written as a text, for example: ```WritesPerMinutePerProjectPerRegion```, ```subscriberPerMinutePerProjectPerRegion```, ```default/USER-100s```. For some quotas, you could estimate the correct format of slash-based “unit” value, but for some, this didn’t work (like the last example I showed earlier). 

Armed with the knowledge of quota names and some formatted units, we harnessed the power of the gcloud command-line tool. Specifically, we employed the command: ```gcloud alpha services quota list --service=<service> --consumer=projects/<projectid> --format=json > output.json``` This command allowed us to export the list of quotas in a more readable JSON format, consolidating crucial information about each quota. The output file was our treasure trove of quota insights. Here, we could discern the format for each service-quota combination. This knowledge was invaluable as it provided a foundation for understanding how quotas were structured. However, it's important to note that while we could gather some unit formats from this output, not all of them were correct or complete and they were formatted using the ```{}``` format, the format not supported by Terraform. These discrepancies meant that we still had to engage in a meticulous process of trial and error, systematically exploring various variations of the unit format until we found the correct one for each specific quota. 

Using this process we were able to generate a list of quotas that we included in our open source project GitHub - [zensoftwarenl/google-cloud-hackathon](https://github.com/zensoftwarenl/google-cloud-hackathon). Next to you being able to use this quota list and project to start managing your quotas through Terraform, I also hope that knowing the steps I took to find the correct format for the unit value of each quota helps you manage your projects better. 

Using the our free and open-source project

Our open-source project is designed to streamline the process of setting up GCP quotas using Terraform. With this project, you can use it locally or within a Terraform Cloud provider, making it easier than ever to manage your cloud resources efficiently.

Using this tool is as simple as updating the values of variables to align with your specific team and role format requirements for your hackathon projects. Whether you need to set up quotas for multiple teams with different access levels or define specific roles for each participant, this open-source solution offers the customisation you need to tailor the quotas to your exact specifications.

But our commitment to your cloud success doesn't stop there. If you find yourself in need of expert guidance and support for your cloud services, we also offer a comprehensive consultancy service. Our team of experienced professionals can assist you in optimising your cloud infrastructure, ensuring cost-effectiveness, security, and performance. [Contact us](https://www.zensoftware.cloud/contact) for more information.

So, whether you're just starting with our open-source project or seeking assistance to supercharge your cloud services, we've got you covered. Reach out to us today and discover how we can empower your hackathon teams and enhance your cloud operations.

Easy automated Container registry management to save on storage costs

When using docker in any meaningful way in production you need to manage your container images. You need to make sure the images are secure and you must prevent keeping too many. Managing container images efficiently is good to prevent nasty cost aspects of cloud. 

When using docker in any meaningful way in production you need to manage your container images. You need to make sure the images are secure and you must prevent keeping too many. Managing container images efficiently is good to prevent nasty cost aspects of cloud. Storage in the cloud is cheap, but not gratis. At ZEN we’ve developed a small and Open Source tool to help you out using The Automated Container Registry Manager.

Consuming valuable storage and inflating costs over time. To address this issue, we developed an Automated Container Registry Manager tailored to combat image bloat directly. With over 500GB of outdated Docker images burdening our resources, manual cleanup was impractical and prone to errors, motivating us to create a reliable automated solution.

Here are three reasons why we think you should start using our Container Registry manager:

By eliminating unnecessary container images, you'll free up valuable storage space and, subsequently, reduce your [cloud infrastructure](/what-we-do/solutions/zen-cloud-landing-zone) costs. Our solution allows you to optimise resource allocation, ensuring that you only pay for what you actually use. 


Our Automated Container Registry Manager is not just efficient but also user-friendly. With a commitment to simplicity, we've designed an open-source solution that is easy to integrate into your existing workflow. Whether you're a seasoned DevOps engineer or a novice developer, our tool empowers you to regain control over your container registry without a steep learning curve. 

Customize the tool to fit your unique requirements with ease. Our solution is highly configurable, allowing you to adapt it to your specific needs. Like for example allowing you to exclude certain container directories to be ignored. Or allowing you to configure what count of images should be stored for legacy purposes and historical reference. 

Moreover, it's idempotent, meaning you can run it multiple times without unintended side effects. This ensures stability and predictability in your container image management, giving you the confidence to automate without worry. 

Embracing an open-source philosophy, we invite you to explore the code, contribute to the community, and customize the solution to fit your unique requirements. This collaborative approach ensures continuous improvement and keeps the tool aligned with industry best practices.

If you find yourself grappling with a container registry overrun by redundant images, our Automated Container Registry Manager is your beacon of hope. It is time to reclaim your digital space and optimize your containerized future!

Paul Backs