Zack Parker: Piling on the Cotap with EC2

(Wen/zack Parker, Cotap CTO) Cotap is a safe enterprise Mobile Information Service software, mainly used to help people better in the work of communication and communication. This article comes from Cotapcto's share of the story of Cotap Entrepreneurship and the role Amazon EC2 plays in its entrepreneurial process.

The following is the translation:

I have been working with the company's co-founder, Mr. Patterson, for years to solve this problem, and we are excited and excited about the new opportunities that mobile devices bring us. More and more people are using mobile portable devices in their pockets to perform fairly complex internet interactions. The mobile Internet is slowly changing the way people work, and we recognize this and hope to develop a software that will make this change happen to people faster.

In the spring of 2013, we set up a cotap, and in the early days of the establishment, I was alone in charge of completing all the back-end construction work. There were some interesting information system services in the market at that time, such as firebase, but I knew that we could not outsource the core parts of our company's products. We need to really take control and build all the basics of our app. At the same time, we are also considering how to be the best Actor outsourcing company abruptly exit the situation Fasheng. Based on the above reasons, we decided to build our own API Information system. Since I have the experience of using Ruby on Rails tools to build information products, it's also natural to start with our API system. I was building a basic Rails API server, and then I started thinking about how to choose the most appropriate host.

Like Heroku This Management Server is a great choice for me, but given the complexity and scale of our backend, there is a predictable cost growth rate. In addition, we do not want to limit their own technology. Our API starts with rails tools, but I know that as we evolve we need to deal with certain tasks, such as uploading files or sending our proxy requests to Third-party APIs, where we need systems that are better suited to these tasks than rail system. We didn't even build a team, let alone build API components. And at the same time I do not want to put my thinking, my ability is limited to do my best to build the greatest infrastructure. At this point, AWS EC2 provide host control and the corresponding high support services to become a technical platform for our natural choice.

I've had the experience of working on a large scale rails application, but this is the first time I've contacted AWS EC2, so I need to get to know the environment. I built a rails host with Apache, passenger, and postgres myself. I keep this app growing and growing and I'm starting to collect a self-assessment scale that includes monitoring, recording, email delivery, database backup and recovery, an asynchronous task queue, and some other projects in terms of the technical requirements for our product system. And the form is growing, and it's slowly evolving into a task that needs to be handled full-time.

Martin Cozzi was the first employee to play the role, and the interview was different from all of my previous interviews. I explained our app to him, and he elaborated on the form I had compiled, and then he began to plan a design that was very similar to our infrastructure structure from a whiteboard. He went into work almost immediately and put his own plan into practice.

And then we have Martin come up with a more detailed description:

The first thing we need to decide is whether we want to finish our top construction at the top of the EC2 or private virtual cloud. VPC at the time was almost everyone's default recognition system, although some companies have completed the migration, but when your pressure becomes larger, you choose to return to choose Ec2-classic is simply a natural thing.

Before making a decision, we described a network architecture that was built primarily of a large number of private instances. Most of the key data storage and private instances of processing are required to be independent of the public instance. We must ensure the privacy and security of our user data. And, regardless of how strong its group protection is, letting each host have a public IP looks like a bad decision. So we chose VPC as our solution.

The effort to design a VPC is not as much as we initially thought, and the combination of a very basic network knowledge and a simple logical structure leads us to build a redundant and resilient infrastructure. We set ourselves a rule from the start, regardless of the number of instances (even a single instance), any instance must be listed after an automatic scaling group, which means that AWS can assume the task of running our example when there is a problem with our hardware. We also decided to reject the use of EBS background instances to avoid forcing people to face the fact that they could not easily take snapshots of the data at design time. Slowly this gradually formed a culture, treating the example, "to be like a cow cannot be like a cat". Whenever someone tries to find or parse our IP address, we do not hesitate to remove the instance. Our culture gives us the greatest benefit-our infrastructure can easily complete the self-healing process without the need for staff to intervene, which really gives us all a lot of sleep.

To do this, the second decision we make is that we never publish any instance manually, either via the CLI or the AWS Web Console. Heartfelt thanks to the AWS Cloud Integration System, our entire infrastructure can be mapped with JSON files and stored by the mirroring control of Git. At any given time, we can get an open port or instance of the home information and look for a git submission that gives us the content. This means that our new members can read our infrastructure from scratch, read all the Git icons, and see how many decisions we made before we made assumptions.

Because everything is code, engineers feel very comfortable, they have enough ownership to modify the infrastructure. Thanks to the technical support of cloudformation and stacker, we can change the size of the cluster or instance within a few minutes, where stacker is a tool that helps us manage the independence between tiers. And that's a big cut in costs because it can shrink or expand our infrastructure very quickly. Finally, by simply changing the area endpoint in the configuration file, we can launch our infrastructure in a new area within hours.

After AWS introduced the new features, we tested these new features to see if we could reduce our infrastructure management time. For example, when we update to version 2.8, we upload the Redis 2.6 instance to ElastiCache. At the same time, we use PostgreSQL on RDS to analyze the database.

Original link: https://medium.com/aws-activate-startup-blog/piling-on-the-nines-with-ec2-at-cotap-e436ea2877ce

If you need to know the latest AWS information or technical documentation to access the AWS Chinese technology community, if you have more questions please ask at the AWS Technology Forum and experts will answer later.

Subscribe to the "AWS Chinese technology Community" micro-credit public number, real-time command of AWS technology and product information!

The AWS Chinese technology community provides an Amazon Web service technical Exchange platform for the vast majority of developers, pushing the latest news, technical videos, technical documents, wonderful technical blogs and other related highlights from AWS, as well as having AWS community experts to communicate with you directly! Join the AWS Chinese technology community to quickly and better understand the AWS cloud computing technology.

                                                                                                                 (Translator/Liu Zijian Zebian/yuping)