100+ Popular IT Courses to Learn.
15+ Categories. 500+ IT Courses to Learn.
100+ Popular IT Courses to Learn.
15+ Categories. 500+ IT Courses to Learn.
.png)
In earlier days, solutions were associated with getting the technology right. The key was technology, the solution was technology and the business expected and paid for technology. Times have changed. Well, at least for those of us taking notice. Today technology is hardly ever a significant problem. Technically, we have a less complicated world. Over the years we have come to understand that technology is basically an arrangement of Processing, Memory, Networking and Storage. We have mastered utilization by using virtualization. We understand horizontal scaling is ‘better’ than vertical scaling and that we can deliver the PMNS more easily in converged and hyperconverged products that also contain the software solution. We have automated many of the key activities to enable reduction in time and costs.
The Cloud paradigm came along and made life easier by helping us to become Service Brokers rather than server admins or network engineers. To the customer we are now Service Brokers; well, we should be. We should be experiencing shorter procurement cycles given that applications and services (the solutions) are delivered from a Service Catalog. Although this can be true in the Public Cloud deployment model and the Software as a Service (SaaS) delivery model, when it comes to Private Cloud procurement we still seem to be stuck in the past and suffer unnecessary delays. Even as Public Cloud services are taken up by more and more businesses the activity of getting the servers, applications and services ‘up there’ still makes for hard going. All the work that is required to design and deliver a Public Cloud hosted environment is still steeped in old-fashioned working practices.
Despite all this change and learning, solution design and implementation is still a thorny job and produces mountains of documentation (some needed, some pointless), endless Gant charts and interminable meetings trying to get the solution in place and delivered. Why is this?
Application Development and Delivery
Application developers use to live in a world of their own. To some extent that is still true. Application development companies don’t usually have network engineers, technical architects and storage SMEs sitting in on the early morning scrums. Applications are developed in isolation and separate from the technical solutions that will need to be created to host, resource and support the application.
In most cases an application is developed for one of two reasons. To provide a solution for an external customer or to provide an application for the business with which it can make money. For instance, a company needs to pay salaries. To do that it needs an application that can pay the salaries, calculate tax and pension information and enter data into a database and then print a payslip all in accordance with the legal framework set out in the Revenue Services ‘rules of engagement’. An application development company will take on that challenge and through a series of iterations it will deliver an application that meets all of the customer and legislative requirements. For a business that wants to make money from an application the scenario is very similar to that for an external customer. The difference is financial in that the business has to justify the cost of having developers on staff creating the application. That cost is set against a forecast of income from the eventual deployment of the application as a service for the business.
In both of the examples there are constants that can make for hard going. In the same way that technical solutions are affected by people, process and politics, so application development is affected by an isolationist practice. Why is this?
Why Is This?
从数据中心基础架构到应用程序到云的所有问题，有一个问题会影响项目的平稳，连接的运行，即“活动筒仓”。
筒仓一直是它的污点。我们是came so used to operating in silos that we didn’t question whether such an arrangement was productive and cost effective. In fact, even now, the majority of IT organizations operate using silos. Solutioning and development in isolation.
解决方案设计和应用程序开发看见the arrival of Lean and Agile as a really effective way to operate and yet, silos remained. Companies operated Agile but, kept the silo way of doing things. Strange when you think about it. Agile means flexible and able to change without trauma. Silo is a ‘pit’ with high sides that makes change very difficult. So, in essence, Agile and silo worked together and made change difficult. Still does.
Silo
这是一个基于筒仓的传统IT环境的现实示例，该环境将要开发和部署应用程序。该过程在某些公司中可能有些差异，而工作头衔可能不一样，但是，这是我在几家大型IT公司工作的经验，并且可以将其视为相当普遍的程序。
应用程序开发人员从概念或请求创建应用程序。要求技术服务（TS）架构师为应用程序基础架构创建高级设计（HLD）。TS建筑师将HLD传递给项目架构师以审查设计。项目架构师将最终的HLD传递给TS Architect。TS架构师向应用程序开发人员解释了设计，并介绍了可能损害应用程序的任何项目。这通常是与其他专家隔离的。HLD被签约购买某人或其他人，项目架构师设定了在为应用程序基础架构创建低级设计（LLD或Build Doc）之前进行适当履行活动。项目架构师必须访问各种主题专家（SME）进行计算，网络，存储和灾难恢复（DR），以找出在LLD中需要哪些技术和要求。关于协议，路由，安全和防火墙规则的详细信息可能很复杂，如果不仔细计划，可能会对应用程序产生负面影响。为了使这一正确，需要咨询业务影响分析专家，以确保可以处理或减轻安全问题，如果存在的情况和合规性问题。 Most applications are deployed to virtual infrastructures which require the involvement of virtualization experts to aid provisioning and automation technologies. All in all, the Project Architect has to consult with many different silos of technology/experts. In the course of this activity the Architect has to constantly return to the application developer to check that what is being planned for the infrastructure is not going to ‘damage’ the application design and make the application ineffective when deployed. Finally, the Service Wrap needs to be put in place to support the application and to meet the non-functional requirements in the Service Level Agreements (SLAs). There could easily be twenty people involved in this process. I haven’t included test and development as this usually waits until the end of the main process along with User Acceptance Testing (UAT). Sometimes there is a separate team that handles this part, sometimes it’s carried out by Operations. Application design also includes the dependency tiers that provide the middleware and database layers. It could be that many more people will need to be involved when those services are included. What is true is that each SME is part of a silo. The project has to consult all these silos. Some are helpful, some are not and there are lots of reasons why No! can be the answer to all questions and suggested solutions.
All the silos and all the people involved make the whole project slow and costly. The analogy is the game of Snakes and Ladders.
DevOps
Although the above example is somewhat crude it is a fair assessment of what application development can be like end-to-end. Everyone in the industry knows that this is the ‘normal’ state of affairs and accept that it is less than perfect. DevOps has begun to appear on the scene as the answer to the traditional silo approach. DevOps attempts to remove the silos and replace them with a collaborative and inclusive activity that is the Project. Application Development and Solution Design benefit from DevOps principles.
What needs to be done to remove silos:
Keys:
Easy to say and hard to do.
大多数中小型企业都喜欢将信息保留给自己。不正确，但许多人。这是多年来发展的传统文化的一部分。工作实践使变革变得困难。变革管理是任何公司可以开始的最具挑战性的任务之一。抵抗将是有弹性的，因为人们要放弃一些东西来获得一些东西很重要。清楚地表明收益是必要的。人们会改变他们的态度和行为，但是，您必须给他们真正的理由。我发现，为中小型企业开展多学科研讨会已证明是一种有效的方法，可以鼓励信息共享和破坏这些“坑壁”。
Explaining to the teams what DevOps is and what it is supposed to achieve is the first part of the educational process. The second is what needs to be done.
State specific, measurable objectives:
What is DevOps
Just like the Cloud paradigm it is simply another way of doing something. Like Cloud it has different definitions depending on to whom you are speaking at the time.
Wikipedia states: Because DevOps is a cultural shift and collaboration between development and operations, there is no single DevOps tool, rather a set or “toolchain” consisting of multiple tools. Generally, DevOps tools fit into one or more categories, which is reflective of the software development and delivery process.
我不认为这是所有DevOps。的发生rence is that DevOps is concerned only with application development and operations. I do not believe that. I believe that DevOps is a paradigm and that like other IT ‘standards’ and paradigms it is relevant to all IT and not just applications. By removing the partitions between each practice in the chain and having all the key players involved from day one, as part of an inclusive and collaborative team, the cycle of application development and solution design becomes a continuous process that doesn’t have to divert to consult each required expert. No-one needs to throw a document over the wall to the next crew. Each document is written within the collaboration process and this has to make the document more relevant and powerful. Imagine that the project team is always in the same room from concept to deployment and each expert is always available to comment on and add to each step of that project. How much better than the traditional method where it can take days to get an answer to a simple question, or to even find the right person to ask.
The mantra is: Develop, Test, Deploy, Monitor, Feedback and so on. This sounds application-orientated. In fact, it can apply to the development of any IT solution. Like ITIL, TOGAF and the Seven Layer Reference Model it can be applied to any and all IT activities from development right through to support services. DevOps puts us all on the same page from the start to the finish.
Don’t allow your company to implement DevOps in isolation and only as a framework for application development. To do that would be to create another silo. Use it for every project and as the default culture for all your teams whether or not they are developers, engineers, architects or operations. And, finally, don’t complicate it. DevOps doesn’t need deep and profound definitions or long and tedious conversations about what it is and how to implement it. Just do it.
.png?width=600&name=Are%20You%20Looking%20For%20IOT%20Training_%20(1).png)
暂时没有评论
Let us know what you think