Azure - Migrating Business to Cloud

Moving apps and services to the Cloud is a significant long-term trend, but that doesn’t mean that cloud migration is right for everyone. While cloud environments are generally scalable, reliable, and highly available, those won’t be the only considerations driving your decision. While making this decision your thoughts should be totally unbiased, so that you can make right choice. 

Benefits of a cloud migration

Ø  Focused on Business needs

o    In complex environments, the costs of maintaining an individual application, are difficult to quantify. Just tracking the uses of the resources, is hard when applications are shared across platforms and a common infrastructure. In Azure, every application resource is quantifiable, billable and can be reported on. Monthly usage reports can be generated that show how each resource is used. This focuses on how much an application costs the people that use it. It means IT can become a cost-generator, rather than a just a cost center.

Ø  Focused on application needs

o    Clients require fast application implementation and deployment, and thus want to focus more on development while reducing infrastructure overhead. Your clients want to expand their business geographically, but you suspect that setting up a multi-region infrastructure – with all the associated maintenance, time, human, and error control effort – is going to be a challenge. With the amount of services Azure has to offer, applications can take advantage of pre-existing services to both reduce the amount of resources an application consumes, and enable developer’s/application architects to focus solely on the application’s business purpose.

Ø  Scalability

o    Your application is experiencing increased traffic and you’re finding it difficult to scale resources on the fly to meet the increasing demand or you are finding that keeping up with growing storage needs is becoming a problem. I n Azure, all resources are flexible, meaning applications can scale up and down as needed. Everything is paid for on a consumption basis, so you also only pay for what you use – so the application that only requires scale once a month, only incurs charges once a month. Storage too can be provisioned for many terabytes, but is only paid for as those terabytes get used. Scale is also automated – applications scale on demand, according to which resources are needed.

Ø  Availability -  In Azure, the PaaS and IaaS services have multiple layers of redundancy designed to ensure 99.95% uptime, and these sit outside of the application layer.

Ø  BC (Business Continuity) \ DR (Disaster Recovery) - Every business should have a disaster recovery and business continuity plan integrated with daily operations. Setting up a disaster recovery system for an entire data center can sometimes nearly double the cost, and also require complex disaster recovery plans. Cloud DR systems can be implemented much more quickly and simply while allowing far better control over resources.  Azure Site Recovery Services enables you to move business continuity and disaster recovery to the cloud. Azure Recovery Services has the capability to coordinate failover and replication of VMs and physical machines. Small and mid-sized enterprises can all benefit from Azure Recovery services to deploy a solid disaster recovery plan in the cloud.

What do you need?

Ø  Infrastructure as a Service (IaaS) gives you control starting at the guest operating system level and through the runtime executables, the data, any management middleware and finally the application.

Ø  Platform as a Service (PaaS) moves more responsibility off of your shoulders. Here, you only need to manage the applications and the data. Everything else is somebody else’s problem.

Ø  Software as a Service (SaaS) takes all the responsibility away. You use the applications and the data without managing any of it.

Public, Private or Hybrid Cloud?

Ø  Public cloud - Organizations that need to quickly ramp performance and has fluctuating capacity and a limited resource pool for the investment. Typically suited for basic SaaS applications like E-Mail, and in an environment where data and applications are not very critical or susceptible to attack and theft.

Ø  Private cloud - Best suited for organizations where applications and data are mission critical and bound by restrictions.

Ø  Hybrid cloud - Most modern organizations are unable to make a decision between taking a completely public or private cloud approach. Transferring storage and computation to the public cloud definitely has its cost advantages, but some mission critical data and applications must remain on premises. A hybrid cloud model makes perfect sense in such a scenario.

o    Let’s imagine that your web application is quickly gaining popularity and users. In order to keep up with the growing demand, you need the underlying resource to scale up dynamically. During peak usage, you should be able to deploy maximum resources serving requests, and when demand drops you should ideally be able to simply drop unneeded resources to save costs. Within a public cloud this is very much possible. But let’s say that, the data your app gathers are highly confidential and just can’t be stored off-premise. This is where a hybrid solution can help by allowing you to choose which components you want to live in the public cloud, and which in your datacenter.

Migration steps to Azure

There’s an old saying that goes, “Easy-to-Use is easy to say!”. The same holds true for migrating workloads and applications to Microsoft Azure. Microsoft recommends four step migration process:

Ø  Discover – Catalog your software and workloads

o    Every application has its integration points, like payment gateways, servers, web services, external storage, and third party vendors. It’s very important to analyze the impact your cloud migration will have on those dependencies. Sometimes you will experience unexpected connectivity or authentication challenges that you’ll be well served identifying and solving up front. The most critical and tedious task is to identify all those integration points. There are some asset discovery tools that can help you discover assets.

Ø  Assess – Categorize applications and workloads

o    Some traditional applications are so complicated and tightly coupled that customers might not be willing to rework it. However, the foremost requirement for any successful migration is that the app should follow a distributed architecture and should be scalable by design. There are some tools on the market that can help you assess your applications’ cloud-readiness.

Ø  Target – Identify the destination for each of your workloads.

Ø  Migrate – Make the actual move.

Angular 2.0 Enterprise Application Development

Transform business to client-side development

Today’s modern companies rely on web-based software to operate efficiently and provide value to their customers. These applications often contain custom and intricate business logic that gives businesses an edge over their competition. The new version of Angular provides a solid foundation to rapidly and efficiently build and scale advanced cross-platform applications.

The most exciting thing about Angular 2 is the fact that it is now much more than a tool for building web applications. Indeed, the main challenge that Angular 2 tackles is the integration of various development platforms. For organizations with applications running on multiple platforms (Web, Mobile Web, Android, iOS, Windows, Mac, Linux) it is often tedious to share code as developers have varying skillsets. This code multiplicity makes the application development process a lot harder than it should be. Angular 2 resolves this issue by allowing developers to reuse components across multiple platforms, therefore creating code that can map across all platforms. This opens the door to huge potential gains in efficiency for organizations, thus reducing project time and cost.

Angular 2 allows businesses to transform to a client-side software development model and pivot in an agile manner while still maintaining strict IT controls on core backend services that drive the business logic behind the scenes.

Angular 2 uses Microsoft TypeScript (a superset of JavaScript) as main programming language. This simplifies the development process by significantly decreasing the number of decisions that developers have to make. Therefore, it allows developers to focus on what really matters: the user experience. Google recommends to use Microsoft’s TypeScript language, which brought improvements such as: Class-based Object Oriented Programming, Generics and Lambdas etc... TypeScript is a superset of ECMAScript 6, and the Angular 2.0 has adopted some of ES6’s features: Iterators, For/Of loops and Reflection.

Key points to use Angular 2

Ø Built for use with TypeScript for fewer errors in code.

Ø Client side will be decoupled from the server side, so development work will progress in parallel.

Ø Amount of JavaScript coding will be reduced, and it will be easier for you to see the potential of the application.

Ø Improved Testability.

Ø Component friendly.

Ø Built-in command line interface for standardized template.

Ø Easier to understand API.

Ø Improved debugging.

TOGAF and Enterprise Architecture

Introduction

As the business environment becomes more sophisticated, the challenges facing organizations are shifting away from questions of efficiency and automation towards questions of complexity management and business agility. Complex webs of existing applications and interfaces create highly complex landscapes where change becomes more and more difficult and the impacts of change become harder to predict and understand. Considering this, Thousands of companies worldwide have adopted and adapted TOGAF to transform their businesses. Since its inception more than two decades ago, TOGAF, an Open Group standard, has grown to become the de facto global framework for creating Enterprise Architectures.

TOGAF

TOGAF is an architecture framework. TOGAF provides the methods and tools for assisting in the acceptance, production, use, and maintenance of an enterprise architecture. It is based on an iterative process model supported by best practices and a re-usable set of existing architecture assets.

Architecture in terms of TOGAF

The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

  

Blend of Business & Enterprise Architecture (TOGAF)

The essence of enterprise architecture is that it provides insight into how various aspects in the enterprise are related. It translates strategy into principles, concepts and models that provide a vision and guidance for design and development. Enterprise architecture is different from solution architecture; it only provides overview and direction and considers the systems to be developed as a black box. Solution architecture opens this black box, describing the structure and decisions in the box. Enterprise architecture is an instrument for determining which Agile projects are valuable. It describes a vision that should be realized, and identifies the applications and projects that are needed to support this vision. Applications are only described as a black box in the enterprise architecture; High-level business requirements identified in the enterprise architecture can be refined into epics and user stories by the Agile project. TOGAF is an important standard with respect to enterprise architecture. TOGAF architecture is the structure of components, their inter relationships and the principles and guidelines governing their design & evolution over time. It is a formal description of a system or a detailed plan of a system at component level to guide its implementation level. TOGAF architecture deals with 4 kinds of architecture:

• Business Architecture
• Deals with business processes, governance, business strategy and organization.
• Application Architecture
• This architecture provides blueprints of individual applications to be deployed, their interactions and their relationships to the core business processes of organization.
• Data Architecture
• This architecture provides the logical and physical data assets and data management resources.
• Technology Architecture
• This architecture contains logical software and hardware capabilities that required to support business, data and application services. It includes networks, communications, IT infrastructure etc...

Why TOGAF?

The TOGAF framework has been tried, tested, validated in many organizations around the world. This framework can be used with other existing management frameworks that your business/organization may use. Organization should pick a framework which will develop the type of artifacts that are needed which are specific to your organization’s needs. When you implement processes, procedures, governance, and structure to manage your enterprise architecture then you should see greater corporate agility, communication, collaboration, and better decision making by corporate executives. What makes TOGAF important to the enterprise architecture community is that it is a framework which is built on open standards. This translates to organizations being able to use TOGAF as their enterprise architecture framework for free. They do not have to pay any organization maintenance cost or anything to implement this framework. Companies are always looking for ways to save money especially with cuts in corporate budgets and the need to do more work with less resources.

Conclusion
In short, enterprise architecture implementation will require a deep knowledge and awareness of all of the business transformation factors that impact transitioning from current state to the visionary state. Any Implementation and Migration Plan has to take both into consideration. Neglecting these and focusing on the technical aspects will invariably result in a lackluster implementation that falls short of realizing the real promise of a visionary enterprise architecture.