2018-04-04
JiangRen Mr
To make things clear — DevOps is a methodology. The idea of this methodology is to create a new mindset. A mindset when developers and operations combine their efforts to achieve a common goal.
Sometimes it is mistakenly confused with a tool or a role. It’s not a tool although it uses a toolchain to automate software delivery and deployment. Nor it’s a position although both operations and developers are expected to extend their responsibilities.
Traditionally, or say 10 years ago, the development team could be roughly divided into developers — people who knew how to write code and operations. For those who still wonder — who on earth are those operations:
They are administrators — sysadmins, network admins, database admins, and all other people who know the infrastructure.
So… The operations were interested in keeping things stable to minimize the chance of software conflicts. While developers mostly cared about new features, new versions, and well, yes bug fixes. The main problem with all the above was the lack of cooperation and communication. As a result, the software couldn’t be delivered at a desired fast pace.
Now, take developers and operations, merge them into a single team, and drive them with the idea of mutual support. You get DevOps.
DevOps methodology allows delivering software frequently with minor iterable changes.
The benefits:
Users receive new features and updates frequently. Your customers receive new features and bug fixes more often. Your company becomes more competitive.
Minimize the chances of outrages. Even when the outrages do happen, everything can be fixed in a matter of minutes (sometimes in a matter of a single refresh) so that users won’t even notice that something is wrong.
Except for the cultural component DevOps methodology became possible thanks to the following approaches:
It all depends on the scale of the project. If your objective is to launch a minimum viable product (MVP) to test your idea, most likely you can live without DevOps practices. If your software has already reached several releases, and it ss time to start thinking about scale and competitiveness — think of DevOps.
It takes more time to set up DevOps environment from scratch. On early stages people get confused why should it take additional time and money to setup Docker and Ansible. The answer is simple — it will take a bit more time now, and as a result, save it in a long term perspective.
In Django Stars, the implementation greatly depends on a customer we deal with. Here is the list of the most frequent “types” of requests:
This is the most frequent request, simply because one day, any company has passed the initial stage of MVP. For such little projects adding a release engineer or system administrator would be an overkill and a waste of customers’ money. These projects are often deployed by developers themselves.
We try to convince the customer that it’s better to sow the seeds of DevOps on this early stage and stick to DevOps common practices like building an app using microservices. In most cases, the developers will also deploy and maintain the product. It allows minimizing the spendings. The product itself is built according to customer preferences, but even if the customer prefers the monolith type of app, opposed to microservices, still we create a good foundation to implement microservices in future.
Most of the time is the hardest case. We like to avoid projects that have been started by someone else and for some reason were abandoned. Still, there are some rare exceptions when the projects are promising enough to take a risk. The cases exclusively depend on the customer. Sometimes, we get an app developed with best DevOps practices in mind, with a request is to upgrade the app from Python 2 to Python 3. While another one required a complete rewrite from the ground up.
This case is the most relevant to a “perfect DevOps world”. Our software engineers are working in a tight conjunction with customer’s operations or DevOps engineers.
Whenever we get a request to implement a new feature our developers provide the following info to customers’ ops teams:
The ops team sets up servers according to developers requirements. This, in turn, makes the further life of our developers easier.
Here are the tools we use on a daily basis no matter what project we deal with:
编程入门班·Python+Web开发入门 第20期
2024/12/11 08:30 (Sydney)
AWS入门一日训练营第二期(布里斯班)
2024/12/14 00:30 (Sydney)
Web全栈班25期暑假特别班(NodeJS+AI)
2024/12/15 08:30 (Sydney)
地址
Level 10b, 144 Edward Street, Brisbane CBD(Headquarter)Level 2, 171 La Trobe St, Melbourne VIC 3000四川省成都市武侯区桂溪街道天府大道中段500号D5东方希望天祥广场B座45A13号Business Hub, 155 Waymouth St, Adelaide SA 5000Disclaimer
JR Academy acknowledges Traditional Owners of Country throughout Australia and recognises the continuing connection to lands, waters and communities. We pay our respect to Aboriginal and Torres Strait Islander cultures; and to Elders past and present. Aboriginal and Torres Strait Islander peoples should be aware that this website may contain images or names of people who have since passed away.
匠人学院网站上的所有内容,包括课程材料、徽标和匠人学院网站上提供的信息,均受澳大利亚政府知识产权法的保护。严禁未经授权使用、销售、分发、复制或修改。违规行为可能会导致法律诉讼。通过访问我们的网站,您同意尊重我们的知识产权。 JR Academy Pty Ltd 保留所有权利,包括专利、商标和版权。任何侵权行为都将受到法律追究。查看用户协议
© 2017-2024 JR Academy Pty Ltd. All rights reserved.
ABN 26621887572