![]() ![]() We’ll answer these questions and explain some of the other issues we encountered. How could we automatically register the build servers with GitLab, which we use for CI/CD?.How could we automate the provisioning of build servers?.How could we automate the macOS software configuration for AMIs?.There were, however, a few “known unknowns” that we could start figuring out right away. What kinds of issues and technical nuances would we encounter as some of the first customers to use this system? We could only guess. ![]() Since we were already using AWS at Grammarly, staying in the same ecosystem would eliminate the need to perform compliance and other legal verifications for a new vendor.įrom the time we started working on this project in November 2020, Amazon’s Mac instances were brand new- they launched at the end of November.Our existing infrastructure toolset was supported, namely Packer for Amazon Machine Image (AMI) management and Terraform for resource provisioning.We expected that Amazon would provide a high level of stability.We were impressed by MacStadium’s Orka solution, where they are managing to run macOS inside Docker containers on Kubernetes-that’s basically rocket science! But in the end, we decided to go with AWS, for several reasons: We ran an extensive evaluation of vendors for a cloud build system and came up with a shortlist that included MacStadium, MacinCloud, and Amazon EC2 Mac instances. Coordinating across time zones and over a long-distance VPN connection meant we had a variety of connectivity problems, slow performance issues, and logistical headaches. For example, Grammarly engineers in San Francisco often needed to VPN into machines in our Kyiv office to build their macOS projects. Performance: An on-premise solution is designed for a team sharing a physical office, posing an obvious challenge for distributed work.You have to physically purchase the hardware (easier said than done during lockdown!), set up all the software, and do a lot of manual configuration on top of that. If it were simple to provision new macOS devices during the pandemic, this might not have been a problem-but even typically, this isn’t so easy and can take a long time. With an on-premise solution, the number of physical devices you have access to at any given time is static. Scalability: As we were rapidly taking on new teammates and projects while working remotely, we’d started to come up against resource limitations.Two main factors drove us to search for a better solution than our on-premise build system for macOS: Here we share specific takeaways and tips to help anyone looking to undertake a similar transition. We’re glad to report that we’ve made the move successfully, after navigating some of the bumps that are to be expected (we were probably among the first AWS customers to switch to the EC2 Mac instances!). We believed this would help us scale our development and achieve a smoother and more standardized build process, resulting in being able to deploy bug fixes and features more quickly. However, new offerings are emerging in this space: Notably, Amazon released support for EC2 Mac instances in November 2020.Īround the same time, we on Grammarly’s Platform team decided to transition our iOS and macOS build environment from our fleet of on-premise Apple devices to these brand-new EC2 Mac instances. Since this hardware is expensive and complex to provision, for years it’s been extremely hard to find a good solution for building iOS and macOS apps in the cloud. They have also been among the trickiest applications for us to develop, build, and release, because Apple requires that products built for its ecosystem are developed on top of Apple hardware. Grammarly for Mac, Grammarly for iPad, Grammarly for Chrome, and Grammarly for Safari are among our most popular product offerings. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |