In our previous blog post, we delved into our AWS architecture. Today, we will discuss the challenges we encountered while fully adopting Infrastructure-as-Code. In this post, we will outline some of the issues we faced with our Terraform setup, including enhancing developer efficiency, improving runtime performance, ensuring security, and reducing
At Astradot, we understand that building a robust and scalable cloud infrastructure is crucial for us to move forward quickly and efficiently. That's why we recently made the decision to rebuild our AWS setup to be truly 'enterprise' grade. During our journey, we realized that while many startups have shared
The enhancements described below are fully backward compatible with existing java code. 1. Default package and class name for main() method While Java requires that the 'entrypoint' point is called main() it needs you to specify the class name containing that method in the MANIFEST.MF file or on the
Our product completely supports Java and we love Java developers. However, internally for our own code, we believe the era of the JVM is coming to an end [https://movingfulcrum.com/the-era-of-the-jvm-is-coming-to-an-end/]. We found these 3 things initially attractive about Go: 1. Instant compile times and program startup for faster
Today we are open sourcing one of our internal tools kafka-schema-sync [https://github.com/astradot/kafka-schema-sync]. One of the problems we face at Astradot is keeping our staging and prod environments in sync with respect to Kafka topics. Engineers can create tons of Kafka topics, with different configurations for each.
Setup Our infrastucture is deployed in AWS us-east-1 region. Elastic Load Balancer (ELB) is used for API endpoints. CNAME records were created in CloudFlare DNS to point to ELB instance. Test We used Datadog Synthetic Monitoring to test our endpoints. Synthetics Monitoring hits an endpoint periodically from around the world.