Three questions to ask before you migrate apps to public cloud

Many firms assume public cloud is the best place to host all apps, but that's not always the case. Before you drink the cloud Kool-Aid, ensure it's a cost-effective move.

The public cloud is an attractive option for many enterprises because of its scalability, speed and pay-as-you-go model. But those benefits don't apply to all workloads -- in fact, some applications could perform poorly or cost more in the cloud.

This means, before you migrate apps to a public infrastructure as a service (IaaS) platform, you need to ensure the move will provide business value.

First, understand what your motivation is for a cloud migration. Do you want lower costs? Do you need more flexibility? Some businesses move to the cloud too fast, only because they assume they should, which could cause issues down the road.

Before you take the big step and migrate apps to the public cloud, start with these three questions:

1. How do I choose which apps to migrate?

Assess your application, and review its requirements -- for both performance and compliance -- to determine if it is a good candidate for the public cloud. Check if the application has any specific network needs or dependencies. Unless you also migrate the systems on which your app depends, including databases, latency could be an issue. Also, review an application's design before you migrate it to the cloud; those apps that frequently read and write to storage systems, for example, could end up costing you more off premises. In general, applications that are "bursty" or have frequent spikes in demand are a good fit for public cloud, while applications that run on a more consistent, predictable basis might be better left in-house.

Cloud providers offer tools, such as Azure Cloud Migration Assessment and Amazon Web Services (AWS) Application Discovery Service, to simplify the assessment process. AWS, Azure and Google also offer pricing calculators to estimate cloud costs.

In addition, determine whether the cloud provider you choose meets your security and compliance requirements. Look at where their data centers are located, especially if you have sensitive data that needs to adhere to strict compliance standards.

2. Which migration approach should I take?

After you decide which applications to migrate, determine a migration method. Two common options are rehost, also known as lift and shift, and refactor, also known as rearchitect.

The lift-and-shift process takes less time to accomplish than refactoring, since developers don't have to change the application's architecture or design -- they just move it as is. But while lift and shift is a simpler approach, it also has drawbacks. For example, if you migrate apps to IaaS without any modifications, they might not be able to take advantage of a key cloud feature: autoscaling. As a result, those applications will still operate the same way they would on an on-premises system -- at peak -- and the enterprise will pay for more cloud storage and compute resources than they actually use.

This makes rearchitecting, or refactoring, a better option for some legacy apps -- even if it's more time-consuming and costly. Lift and shift, on the other hand, is best for cloud disaster recovery.

Do not migrate apps to the cloud too quickly -- start with apps that are the most cloud-ready and that have the least amount of sensitive data. After you run a pilot, test the application, get a feel for the process and then move onto more critical applications.

3. What are my options for cloud migration tools?

Migration is a complex process that comes with risk and the potential for high costs. There are both cloud provider-native and third-party tools that can aid organizations through the process. If an enterprise needs to move large amounts of data to the cloud, it can also perform an offline data migration. This requires an organization to store its data on physical disks and then ship the disks to its cloud provider. While this method might seem old-school, it can be more cost-effective than a migration via a network if you have terabytes of data. Offline data migration services from top cloud providers include AWS Snowball, AWS Snowmobile, Google Transfer Appliance and Azure Import/Export.

Source : searchcloudcomputing.techtarget

Read More

4 requirements of a low-code development platform

Many enterprises are adopting low-code platforms for their ability to enable a broad range of developers to rapidly build and deploy custom web and mobile apps—without the need for time-consuming coding.

Organisations focused on delivering applications for innovation, customer engagement, operational efficiency, or legacy migration are recognising the inherent business value and time-to-market advantages of low-code development platforms.

With business demand for custom applications soaring, it’s clear that traditional development approaches simply can’t keep pace. According to Gartner, through 2021, market demand for app development will grow at least five times faster than IT capacity to deliver it.

So what exactly is a ‘low-code’ development approach? How can it help organisations meet surging demand for applications? What are the key capabilities of a low-code development platform?

 The next step for IT and business leaders is to evaluate platforms carefully and choose the approach that meets your organisation’s needs, now and in future.

Defining low-code development

Forrester defines low – code development platforms as: Products and/or cloud services for application development that employ visual, declarative techniques instead of programming and are available to customers at low- or no-cost in money and training time to begin, with costs rising in proportion of the business value of the platforms.

There are several important features of any low-code development platform:

1. Model-driven development

Low-code platforms offer more intuitive ways to build applications, minimising the use of coding. Model-driven development (MDD) uses visual models for defining an application’s data models, business logic, user interfaces, etc.

This approach enables a range of users—from professional developers to citizen developers—to visually model full-stack web and mobile applications. Using visual tools can result in 10x productivity gains over traditional approaches. As capability matures and organisations begin to scale, some organisations have seen up to 20 times productivity.

2. Reusability

Productivity can be further accelerated with low-code development platforms that promote reusability through an App Store populated with out-of-the-box templates, widgets, plug-ins, business components, and connectors to emerging technologies.

The platform may also offer a private app store, whereby an organisation can distribute company-specific IP for reuse across development teams. In either scenario, building apps becomes more like visually orchestrating the necessary building blocks, versus reinventing the wheel each project.

3. Support beyond just the build phase

It’s easy to fall into the trap of viewing low-code platforms only as a way to speed the build phase. In reality, many platforms are designed to support the entire app lifecycle: design, build, deploy, manage and iterate.

As such, usually include collaboration tools, agile project management, cloud-native deployment, application governance tools, and feedback tools. This is an important part of the time-to-market advantage, with a seamless way to move apps along the lifecycle, particularly in terms of deployment.

4. Cloud-native deployment

Some low-code development platforms offer the flexibility to deploy and manage applications in the cloud of your choice, or even on premises. Offering automated deployment along with a cloud-native, stateless architecture enables out-of-the-box high availability and fail over to support large-scale deployments, particularly in an enterprise context.

Key benefits of a low-code platform

In many business sectors today, the barriers to entry for digital competitors are so low that new players are coming out of nowhere and disrupting industries through technology-led products, services, and business models.

To stay ahead of the competition, organisations must constantly find new ways to do things better, faster and cheaper; and to engage customers and partners in new ways. The challenge is that, while the demand for custom apps has never been higher, traditional development approaches simply can’t keep pace.

It’s clear that businesses need a faster way to deliver applications—and low-code development platforms provide a proven way to shorten time-to-value for new applications. The fundamental value of a low-code development platform is that it brings IT and the business together, enabling more rapid, iterative, and collaborative development.

Applications can be rapidly built, seamlessly deployed and easily changed—all without the need for low-level coding. In addition, these platforms provide an excellent communication mechanism to align business and IT stakeholders, thereby ensuring greater software quality and more successful business outcomes.

The next step for IT and business leaders is to evaluate platforms carefully and choose the approach that meets your organisation’s needs, now and in future.

Source : information – age

Read More

3 Tips for Transitioning to DevOps in Financial Services

Anyone who works in IT for financial services understands the pressure to keep up with a competitive market, where customers expect all their services to be online and where regulations shift rapidly. It’s this pressure to continually deliver improved services at a fast rate that moved Freedom Mortgage, a top U.S. mortgage provider, towards adopting DevOps.

As the point person for driving the organization’s DevOps initiative, Ting Cosper, Director, Enterprise IT Change Management and DevOps, understood that adopting DevOps was not a luxury—their ability to respond quickly depended on it. But change does not come easy, and it was up to Ting to lay the groundwork for the transition. Ting talked about his experiences a few weeks ago at the XebiaLabs DevOps Leadership Summit. Below are 3 tips he shared for transitioning to DevOps.

1. Start with People and Processes

Ting’s team manages change management. Any changes to tools, systems and processes go through them. Their job is to make sure things are as solid as possible before sending software to production.

Inconsistency across groups in managing revisions and storing them to secure repositories was a key problem for them. On top of that, the team was using manual processes to deploy changes, which took a toll on their small staff because someone had to be on call nights and weekends to make them. It might have been tempting to immediately look for tools to address these problems. However, tools were not the main issue. Rather, it was the lack of standardization that was creating conflicts and burning people out.

So, if you’re considering doing DevOps and plan to dive into tools as your first order of business, Ting’s advice is to stop. Tools are important, but you can’t buy a tool that will “do DevOps.” Instead, Ting’s top priority was improving how people interact with each other and with technology to drive performance. He wanted to standardize their processes and reduce manual work that was hurting their efficiency and the quality of life for their employees. In addition, he needed to show management how the organization was losing money by continuing to follow the status quo.

2. Reflect and Document

Before he could convince anyone else to accept change, some reflection was necessary. Ting suggests that, before jumping into a DevOps initiative, think about what your organization is doing right and wrong. Maybe your developers are good but you fall short when it’s time to deliver, or maybe QA needs extra resources. Taking a hard look in this way helps you understand your processes: what you’re doing, where the waste is, and where you can improve. For Freedom Mortgage, their delivery team was very efficient with execution but fell short on documentation, which is crucial for communicating your intentions.

An important part of documentation is calculating the cost of your processes. After gathering metrics on their change system, Ting and his team were able show that, while there was a drastic drop in failed changes over the course of several months, the financial and human costs of doing so were too large. Their staff was consistently working weekends, and overtime costs were upwards of $200K in one year alone—excluding follow up on Monday to put out fires and have development do fixes. Show people, especially management, the ROI of hard and soft saves that will result from your plan and you’ll get their attention.

3. Find the Right Tools

Once you’ve figured out where to improve your processes, it’s time to look at DevOps tools. Ting’s team wanted to start by getting a better handle on their deployments, so they researched leading DevOps solutions companies. While product quality was a high priority, they also wanted a vendor who would share practical knowledge about getting their initiative going and scaling it in a controlled way.

They chose XebiaLabs because they preferred the interface and modeling feature of XL Deploy and believed that XebiaLabs would be their partner throughout the transition. Bringing in XL Deploy and XL Release is giving them a better handle on how to do their deployments and release software. XebiaLabs products also enabled them to show the larger community that there’s a better way to manage the pipeline and get software into production.

The Results So Far

Ting and his team began putting their new processes in place in January. Although it’s still early, they’ve already implemented controls that enable consistency across teams. And people are starting to see the benefits: there’s less conflict between groups, individuals don’t feel blocked from getting their work done, there are fewer budgeting issues, and it’s much easier to train new people or to cover if someone is sick or on vacation. It’s also simpler to expand or contract a team as needed for a project.

Do’s and Don’ts

Based on Ting’s experience, he offers some do’s and don’ts for successfully transitioning to DevOps:

Do…

• ·         prepare to be successful. Focus on the end-result and how the investment will pay off in the long run. Spread that message to all your stakeholders.
• ·         your homework and document everything. You are going to have to explain yourself every step of the way.
• ·         communicate and celebrate each milestone. If you make it a big deal, so will everyone else. Celebrate even small achievements, and highlight why they matter.
• ·         financial analysis. He or she who gathers the information decides how to tell the story. People will find ways to make it financially difficult to move forward, so make sure you have the data to justify your plan.

Don’t…

• ·         be discouraged by setbacks. Not everything is going to go smoothly. Setbacks will happen, but don’t let them deter you.
• ·         expect overnight results. Change comes with some frustration and pain, so be patient but consistent. Set an agenda and stay the course.
• ·         bite off more than you can chew. Don’t overpromise. Set realistic expectations right from the start and live up to them.

Finally, believe that what you’re doing will deliver value for the organization. Document your journey, practice patience, and press forward with confidence.

Source: blog.xebialabs

Read More

5 Tips for Leading a DevOps Transformation in Your Organization

Change is hard.

It’s hard personally when we’re trying to build new habits to make us healthier, like eating better, working out, and getting enough sleep. It’s especially hard for organizations trying to do much the same thing: adopt new ways of working to produce better results

IIf you’re a believer in DevOps and have tried to help others see the light, you may have run into some…challenges, like:
• Lack of awareness or understanding of DevOps patterns and practices
• Opposition from thinking rooted in “the old way” of working, and
• Inability to relate to the perspectives of individuals in different roles and at different levels within the organization
Change is possible. It might be slow and bumpy, but it will be beautiful when it happens. It just takes time, persistence, and the right approach.
Here’s how you can lead change within your organization and be more successful in your efforts to bring others in different roles and at different levels into the DevOps movement.
1. Understand their priorities
We have to start by meeting people where they are rather than forcing them to come to us. That’s what leading is all about. We need to take the time to understand the different perspectives of the people we’re engaging and find out what they care about. The more we can connect what we’re trying to accomplish to what they care about, the more successful we’ll be. For example, an executive cares about accomplishing business goals and meeting the organizational mission. How can we demonstrate that DevOps helps accomplish those goals?
2. Appreciate the issues they face
Different people in different roles encounter different issues in their pursuit of what they care about and their goals. Discover what those issues are and try to relate to the challenges those issues present for people trying to do their jobs. For example, a middle manager might be faced with budget cuts, while still being asked to do more with less. How can we show them that DevOps helps address those issues?
3. Identify the target mindset
DevOps patterns and practices represent a new way of working, and that requires a new way of thinking. Conventional wisdom doesn’t always apply. In fact, in many situations, applying conventional wisdom is exactly the wrong thing to do. Remember the famous quote from Adrian Cockcroft, the former chief architect at Netflix, who said, “Do painful things more frequently so you can make it less painful.” Unconventional, to say the least, but exactly correct. How can you shift people’s mindset from wanting to control change to embracing change? Or managing through a “command and control” approach to empowering teams?
4. Develop your plan
Every organization is different and therefore every plan should be different. There is no “one size fits all” approach to leading change. What works for one organization in one context may be a total flop somewhere else. That’s why we have to take the time to understand our organization and the people in it, their goals and priorities, the issues they face, and how they think. Only then can we assemble the right set of tactics that will produce the kind of change we want. Do we need to start promoting collaboration and sharing? Do we need to map the value stream? Do we need to make work visible? Maybe. It depends on what you’ve discovered in your efforts to learn what makes everyone tick.
5. Execute your tactics
Once you’ve developed your plan, now it’s time to execute it. Start small and build on the successes over time. Don’t try tackling too much at once. Remember the lean principle of limiting work in progress? It applies to leading change, too. Other DevOps concepts that also apply here are frequent releases, fast feedback, and continuous improvement. Experiment with different tactics to see what works and what doesn’t, incorporate what you learn into your plan, and always keep trying to get better. Finally, realize your DevOps journey is never “done” – you’re always working toward “better.” For change agents, that should be an exciting thought.
If you want more information about how to lead change more effectively, check out the Leading Change whitepaper. It’s a great resource to help you relate better to others within your organization and create a plan to help your organization adopt DevOps patterns and practices. Good luck in your journey!

Source: Blog.xebialabs

Read More