mti - perencanaan infrastruktur bh-2002/v1.0/1 adaptive infrastructure: identifying and using...

MTI - Perencanaan InfrastrukturBH-2002/v1.0/1

Adaptive Infrastructure:Identifying and Using Pattern

Sjarif Abdat ([email protected])

Universitas Indonesia


Reference: The Adaptive Enterprise: IT Infrastructure Strategies to Manage

Change and Enable GrowthBruce Robertson and Valentin SribarAddison Wesley, 2002


Pattern-based

Instead of developing infrastructure from the ground up for each new application, businesses can leverage a limited number of reusable infrastructure patterns.


Designing for the future

It is impractical and inefficient to allow infrastructure and business process to grow unchecked with separate decisions and implementations each time an applications is deployed

Recognizing patterns allows you to reuse existing technology, business process, and the skills of existing personnel

The pattern set must be variable enough to cover all major application requirements, but limited in number to deliver the benefits of a simplified environment.

Patterns must also provide sufficient detail to enable the design and implementation of high-quality, end-to-end solutions with minimal customization.


Relating Patterns to Platforms


Relating Patterns to Platforms

Pattern are the information, insight, and experience – the “what is” and “how to” – that are common to an existing class of application

This information is captured in a form that makes it easier to reuse with future applications of the same class.

Patterns also capture experience and best practices for projects that result from real apps requests by business

They emphasize end-to-end reuse in a logical rather than physical.

Patterns deal with applications, platforms deal with technologies

Platform requirements are IT-driven, pattern requirements are more directly driven by business needs

Patterns are designed to address application requirements by providing a proven and tested solution


Why So Few Patterns

80%-90% of all infrastructure needs can be consistently accommodated by a set of less than ten patterns

The specifics of these patterns may change to accommodate new technologies

It should be small When you have too many options, complexity

becomes a problem. It’s difficult to maintain expertise in too many

areas, designing a limited set of patterns will help you keep your focus.

Keep in mind the 80/20 rule and leave the last 20% of differences outside of the standards

Are patterns just for new infrastructure?


The Starter Kit

META Group recognize a set nine starter patterns in three basic interaction types: Transact patterns

Applications in which business data is written and stored for long period of time, such as online customer orders and other transactions

Publish patternsApplications with read-only data, such as online marketing information

Collaborate patternsApplications where information contained in files and documents is shared between two or more users, such as a product design document shared by a development team.


The Starter Kit


Pattern Maturity


Transact Patterns

Transact pattern include any application that “writes” structured information to a system or a data set

Transactions let you Create, Read, Update, and Delete (CRUD)

A DBMS is usually a standard component of this patterns Require ACID properties (Atomic, Consistent, Isolated, and

Durable) Sub-classified using the following logical tiered structured:

1-Tier Transact,or Host Transact, where all data processing is done on the host system in a monolithic application

2-Tier Transact, which typically bring the presentation and business logic to the client side, leaving the database management on the server

3/N-Tier Transact,which, in addition to separating data management like 2-Tier, separates the presentation logic from the business logic


1-Tier Transact Pattern

This patterns includes batch applications or online transaction processing (OLTP) without logical abstraction between the presentation, application, and data logic.

Most mainframe implementations fall into the 1-Tier Transact Pattern

The entire application, including the database, business logic, and presentation logic, is hosted on a single, high-end server

Great for serving large user populations with massive transaction rates, fast response times and high availability



Benefits: Availability. The host pattern’s availability is common

strength familiar to infrastructure developer Scalability. This patterns excels in the number of

concurrent users it can support Reliability. This pattern is also the most reliable.

System recovery problems are often handled automatically



Weaknesses: Expensive. Users have to pay a premium price for

mainframe hardware and software licenses. Inflexible. Changing the system requires a significant

engineering effort. Lacking agility. The shared nature of applications can

generate significant interrelated workload dependencies.

Lack of applications. Package application support is declining

Resource-intensive.



Best Practices: Put wrappers around legacy host code to

encapsulate the components and make them reusable

Avoid using this pattern for new applications Don’t use components optimized for this pattern in

other patterns Minimize the investment in upgrading this pattern

Futures: No new applications should be based on this

pattern.



This pattern involves a smart PC on the desktop communicating directly with a back-end database server

It also includes web servers that intertwine CGI/ASP/JSP presentation and application logic

The heavy integration of application logic and screen presentation logic make app-to-app integration difficult

Best suited for implementation on a LAN, in an environment where bandwidth are high and latency are low

SQL statements and database access middleware typically perform poorly over higher latency and low bandwidth WAN

How can you tell if an application is 2-Tier or 3-Tier?



Benefits: Speed. The best choice for applications being deployed

in a high-risk, volatile business environment, where business cycle are measured in weeks rather than months or years

Rapid development. Delivery can take place at a rapid clip



Weaknesses: Lack of scalability Security vulnerabilities Sourcing limitation Presentation limitation Lack of API Hidden Cost



Best Practices: Limit this pattern to small-scale applications in

a LAN-based environment Be wary of adapting this pattern to WAN-based

clients using a terminal server Don’t use the Web version of this pattern for

large-scale applications Take advantage of this pattern for rapid

prototyping



Futures: Prototyping and piloting will continue to use

this pattern Smart PC version wanes ISVs slowly migrate from this pattern to N-Tier

Transact


3/N-Tier Transact Pattern

This pattern consist of a thin client carrying presentation-logic only, communicating with a client-neutral, server-based applications, and a back-end database server

The most scalable and flexible client/server transaction pattern

Users can be highly decentralized (WAN-friendly) Flexible to integrate with other applications or

points of interaction. Offers the greatest distribution of processing

functionality in a transactional environment Clients in this pattern tend to be thin, and shared

business logic can be supported from multiple point of interaction



Benefits: Scalability. Distributing the processing load on multiple

server tiers provides significant scalabilityo Requires more design effort to partition application functions and

limit dependencies

Security. Web SSO products provide multi tier security with role-based resource authorization

Presentation. All user interfaces can leverage the same application logic, both logical and physical

API. Ability to use APIs independently of the application’s presentations is the key advantage

o Reduces the cost of EAI because of sharing APIs between applications reduces the time and expense required to integrate the apps



Weaknesses: Need customization. Requires significant

customization at application and tool levels Misunderstood. Web server based is not

always 3/N-Tier Expensive. System integrators maintain that

integration and implementation expenses will exceed hardware and software by a 4-to-1 ratio.



Best Practices: Develop Transactional Integration services to match

3/N-Tier applications Work closely with application developers in the early

stages, as they build or buy tools Use scale-out stateless farm architecture Use experience gained from existing OLTP DBMS and

server OS/hardware platforms, even if other server tier platforms are different

Do not replicate OLTP data to scale Take advantage of 3/N-tier pattern benefits when

scaling and integrating with other applications Develop a Test Lab, including equipment and

procedures for investigating the infrastructure impact of various patterns and services



Futures: Continue to be the preferred choice for

transactional applications ISVs slowly migrate to this pattern Better app development tools supporting this

pattern


Stateless Farm Architecture and Scale-Up Design

Scalability and availability can be approached using: Scale-up Scale-out

Stateless Farm Design: Application designer understand how to build statelessness

into Web applications HTTP makes it possible -> IP redirection, to distribute the

load to number of Web servers For transactional apps, requirement still exists to maintain

user session information. Application state is achieved using cookies, decorated

URLs, or persistence mechanisms provided by the load balancers.

Storing state in the database is the most safe and reliable design, even it it limits performance



Clustering Database General-purposes commercial database apps are more

difficult to parallelize, given the need to maintain state centrally

Best practice is to use clusters primarily to enhance DBMS server availability, not to extend scalability

Scalability issues will be addressed by new software products, such as Oracle 9i Real Application Cluster (RAC), and new hardware technologies.



Clustering Other Servers To scale Web applications can be addressed by

implementing DNS round-robin load balancing. Simple DNS policies are not sophisticated enough to

avoid unhealthy servers in cluster Vendor have developed server load balancer (SLB) and

network load balancer (NLB) products to improve reliability, performance, and manageability of server clusters

They distribute the processing load based on various policies, including round-robin, least connections, and CPU load

The three core advantages to NLB solutions are:o Increased redundancyo Better performanceo Easier management


Publish Patterns

Publish patterns include most applications that provide read-only and data analysis access

Scaling these infrastructures is usually a matter of replicating the data as much as needed to support volume and reliability

Publish applications are the most easily and commonly outsourced (when the goal is to serve very large number of users over large geographies)

Sub-classified as: Client/Server Publish, usually leveraging complex GUI

analysis tools Web Publish, where the data-access is initiated in a browser Stream Publish, an emerging pattern that covers near real-

time audio and video downloads


Client/Server Publish Patterns

This pattern is defined by the use of a smart PC, such as a sophisticated business intelligent client, with session-oriented protocols.

Best used for implementing sophisticated data analysis capabilities for small, well-defined user base.

Applications that fit this pattern are online analytical processing (OLAP) tools and reporting-intensive application

This client/server pattern is the most popular Publish pattern inside the enterprise



Fig 3.8



Benefits: Highly adaptive. It reduces the number of interface and

the number of extractions that have to be performed on the operational system

Weaknesses: Resource-intensive. Client code size and bandwidth

requirements make this pattern less easily scalable and deployable (tend to be restricted to LAN use)

Unpredictable demand. It is not uncommon for the answer to a query to be 100 to 200 megabytes or more in size


Client/Server Publish Pattern

Best Practices: Developers must pay close attention to modeling in order to

maintain system performance Manage data access closely, both educated and uneducated

users may be accessing these applications, and a tiny mistake in an SQL command can bring a data mart to its knees

Consider using a separate OLAP server to optimize performance by pre-calculating and storing results for common queries

Use this pattern only for data-intensive, read-only applications Due to the bandwidth requirements, this type of pattern

should typically be used in a LAN environment only You should use one of the Transaction pattern to handle the

write-back/change requirements resulting from analyses Create a unified analytic service using a Data

Warehouse/Operation Data Store (DW/ODS) Use publish-specific tools such as OLAP analysis tools rather

than VB or PowerBuilder



Futures: Client-based slicing and dicing of data will remain

popular, especially for disconnected users Convergence of Web and Client/Server publish with

ability to move transparently between them


Web Publish Patterns

This pattern is defined by the use of an HTML browser and HTTP protocol to enable read-only access to structured XML or HTML documents

More flexible than Client/Server Publish pattern in supporting large, less well-defined user groups

Most popular for applications reaching beyond the enterprise boundaries

Many Web sites today use a combination of Publish and Transact patterns

However, infrastructure planner should separate these distinct functions to get a better picture of the infrastructure that is needed for each activity



Benefits: Due to the maturity of this pattern, many solid tools are

available for developing read-only Web publishing apps Speed of initial development Wide availability of Web hosting service provider Scalability is very simple to achieve by scale out, rather

than scale up (stateless farm architecture) Performance-enhancement solution:

o Network load balancer and multi-site balancingo Compressiono Caching (reverse caching in DC, client caching,

intermediate ISP caching)o Content delivery network (CDN) services like Akamaio Traffic or rate shapping



Weaknesses: Difficult to manage scale or load on e-Business Web

sites that fit this pattern Difficult to change the presentation logic from Web to

non-Web presentations without completely rebuilding the application

Publishing to multiple points of interaction is still a work in progress


Web Publish Pattern

Best Practices: Focus on availability first, then on throughput and response

time Plan for at least two-way redundancy, even for internal

systems Examine Web-hosting service providers for designs and

sourcing Consider using Content Delivery Network (CDN) services

for static content, but only for very large audiences Scale out (duplicate and replicate) Web and data servers

with load balancers Support multiple point of interactions (or at least plan on

this in the future Manage, limit, or disallow direct access to transactional

data Avoid running transactional applications on infra-structure

designed for the Web Publish pattern Create a unified analytical integration service via DW/ODS


Web Publish Pattern

Best Practices (cont): Don’t use expensive Online Transaction Processing database Leverage less expensive hardware and software in general for

data storage component. Don’t neglect security issues. Be sure to guard against data

defacement and denial of service attacks Coordinate with marketing personnel and other business

decision-makers, to estimate the impact of business cycles, marketing campaigns and other business variables on application workloads

Design for outsourcing. Even if you decide not to outsource now, this is an increasingly cost-effective option for many businesses, and may be advantageous in the future

Install response time and load monitoring services for business-critical applications

Take a service-centric approach. Once you have optimized this pattern, it can be widely reused with minimal or no customization.



Futures: N-Tier publishing based on XML, XSLT, and XQL Convergence of Web and Client/Server publish with the

ability to move transparently between them


Stream Publish Patterns

This pattern is used for real-time publishing of streaming content to “multimedia player”

Streaming plays the file in near real-time as it download

The latency requirements of real-time multimedia delivery are critical

Stream publish is only one-way Streaming multimedia requires great changes in

user behavior, Web site loads, and network configuration



Benefits Usability.

Streaming content is much easier to use simply because little interactivity is involved

Business value.Streaming content can make web sites more dramatic and interesting (increase customer retention)

Clear choiceVendor solution are coalescing slowly, which makes specifying solutions easier to do



Weaknesses: Bandwidth-intensive

which also can mean expensive Unpredictable result

Unpredictable and variable network can affect the streaming quality

Unpredictable demandE-Business or consumer-focused sites normally have an unknown external user base.


Stream Publish Pattern

Best Practices: Find a qualified service provider to host large-scale content

streaming. Be sure they are equipped to handle dynamic bandwidth needs quickly and efficiently during peak demand

Don’t use gratuitous streaming content on web pages, since it complicate infrastructure requirements while perhaps providing little business value

Monitor usage carefully. Traffic spikes are common with streaming content, and poor quality of service can largely negate the business benefits

Use traffic shaping to control the impact of streaming content on other Web applications

Use multicasting whenever possible for internal viewing of popular streaming content

Internally, consider using scheduled replication of content to servers that are logically and physically closer to large user populations, instead of running streams over WAN.

Monitor corporate intranet sites for overuse of streaming media links



Futures: Increasingly advanced compression algorithms will

improve the streaming quality Streaming publishing will evolve into multicasting CDN are adding streaming support to their distributed

caching system


Collaborate Patterns

The collaborate pattern involves peer-to-peer communication, usually centered on shared documents or groups of documents

Driven by the need to share and modify calendars, text documents, and design drawings, along with growth of more advanced collaboration techniques using streaming audio and video

True collaboration requires multiple human beings working directly together, through the asynchronous time between their activities

It is essential to have unified, highly centralized, and singular infrastructure solutions

Differentiated patterns in this category include: Real-time collaborate pattern Store-and-forward collaborate pattern Structured collaborate pattern


Real-Time Collaborate Patterns

This pattern is quite similar to the stream publish pattern, because both involve enabling real-time transmission of audio and video.

Collaboration implies two-way information exchange

Applications in this category use streaming audio, video, graphics, or text to share information between users.

The communication can flow either through a server or straight from peer-to-peer.

Example: MS NetMeeting, VoIP, IM, any type of videoconferencing



Benefits: Lower costs

Running real-time collaborate activities over a shared network can enable significant sharing without extra costs.

Better communicationHelp boost the flow of information and idea, particularly globally.

Customer retention



Weaknesses: Bleeding edge Plug-in requirements Security impacts Network issues


Real-Time Collaborate Pattern

Best Practices: Identify applications that fit this category early and study

them carefully Determine real capabilities—not just application features—

based on your existing or planned infrastructure Estimate the real costs of infrastructure upgrades, and

weigh them carefully against expected business benefits Explore the many options for improving quality, including:

o Quality of service (QoS) features in networking equipment and networking services that can help to reduce latency, variation in latency, and jitter

o Running protocols over UDP to reduce some of the latency caused by retransmissions that are required using TCP.

o Scheduled collaboration using broadcast and multicast technologies, to better control and manage bandwidth demands.

o Bandwidth upgrades to the existing infrastructure, or dedicated networks for collaborative applications.



Futures: The value of new ways of doing business and interacting

with various constituencies will drive continued innovation in this pattern

QoS support within intranets and then Internet makes this pattern more available and affordable

Bandwidth prices will continue to fall Technology and product options will continue their

progress toward cheaper, faster, and better


Store-and-Forward Collaborate Patterns

This pattern involves the basic transfer, replication, and storage of files or documents.

Common examples include email, distributed file system, print queues.

The most mature and popular collaborate pattern This pattern should remain the most

decentralized in nature



Benefits: Maturity. Mature standards are common in this pattern Collaborative. This pattern offers simple collaboration

solutions that are good enough for many needs Good model. This pattern can serve as model for

maturity in other patterns Undemanding. The nature of store-and-forward makes

network impact light, particularly on WANs Easy component selection



Weaknesses: Hard to upgrade. Since this pattern is the most

distributed, changing standards means changing very many instances of solutions.

Hard to support. Still difficult to provide Help Desk support to a vast group of users.

Data security. Much data can be located on local hard drives.

Slow pace of change.


Store-and-Forward Collaborate Pattern

Best Practices: Establish single standards for e-mail products, calendar

products, office automation, and other similar component throughout the enterprise

If you can’t standardize on a single product, use established standards, such as SMTP, S/MIME, and others, to make e-mail system interoperable.

Provide a single file, print, directory, and security solution for this pattern

Provide just a few common desktop configuration and stick to them

Enhance cost recovery by charging a per-desktop fee for all investments in all required systems

Establish centralized control to ensure coordination and standardization across business units. This includes controlling standard schema for directories across multiple organizations, locations, user groups, etc.



Futures: Directory services decoupled from NOS File systems decoupled from OS (e.g., network-attached

printers)


Structured Collaborate Patterns

Known as workflow or document management, provides many important integrity-checking features

Requires a longer implementation cycle and is more expensive

Common examples: Lotus notes groupware and workflow application, document management apps, web content management, and shared groupware calendar

Deployed much more centrally that traditional store-and-forward applications



Fig 3.13



Benefits: Automation/integrity checking.

These solutions have strong automation features supported by infrastructure such as check in/check out.

Good opportunity.Thinking of these solutions as a separate pattern may help clarify infrastructure decisions.

Weaknesses: Uncertainties.

Untried solutions require significant testing Little leverage.


Structured Collaborate Pattern

Best Practices: Employ check-in/check-out document

management systems or strong workflow solutions as required

Don’t allow large document collaboration over Internet connection

Extend standard Store-and-Forward solutions as much as possible to take advantage of existing systems and user familiarity. However, don’t hesitate to deploy more structured applications when the business value is clear

Keep solutions as small in scope as possible. The smaller and more localized the workgroup, the easier it is to deploy a successful solution for structured collaboration



Futures: Convergence of this pattern and 3/N-Tier transact Becoming more transactional and 3/N-Tier evolving

towards workflow and long-lived transactions


Adapting Pattern For Your Organization

What Patterns Do I Need? Extra Patterns Not Covered Subdividing Patterns Applying Multiple Patterns


What Patterns Do I Need?

First look at your business processes, your applications, and your existing infrastructure solutions and start analyzing where the major patterns lie: Which patterns do I use a lot? Which pattern cover the applications most critical to the business?

Any patterns that answer above questions should be automatically entered into your list of required pattern

Some patterns won’t be required at all Use the 80/20 rule. Include the smallest number of patterns that provide the maximum

value toward infrastructure planning Try to keep below 10 the number of patterns in which you want to

excel. Focus on those pattern that offer significant ramifications for future

application delivery, while spending less time on those pattern that are more mature

Less patterns will require more planning and design to drive toward maturity


Extra Patterns Not Covered

Not all business alike, it’s very possible that the patterns discussed here do not include an important aspect of your business

Other infrastructure patterns not reflected here might include: SCADA PBX

Your choice of preventative patterns will also be guided by the different service levels your organization needs to achieve in each instance.

Such as developing a “high availability pattern” or a pilot/prototype pattern”


Subdividing Patterns

Your business applications might fall into a single pattern, and need to further refine into sub-pattern

Before breaking a pattern apart, consider the following issues: Is the infrastructure different enough to be worth planning it

separately? Is the infrastructure highly disruptive to the business as a

whole or to other sets of applications? Do you use the applications, and therefore this infrastructure,

a lot? Do you have two parallel product choices that are both

commonly used, yet each requires somewhat different infrastructure?

Do you have two instances of a pattern that represent different service-level requirements.


Applying Multiple Patterns

Some large-scale applications might require two or more patterns

You shouldn’t feel obligated to run every part of an application on a single infrastructure or pattern

Using pattern helps identify when staging of a single application across multiple infrastructure can help maximize efficiency and minimize redundancy

Example: Web Portal


Creating an Infrastructure Portfolio

It’s vital to keep a portfolio of pattern. Besides patterns you have to maintain platforms,

services, projects, projects, processes, and personnel into the portfolio.

A portfolio is composed of four basic parts: Standards. Standards that control both the external and

internal structure of the class of entities stored in the portfolio:

o Use case matcheso A reference architectureo A reference list or manifest of required components and/or

service Historical information Inventory template Actual inventory


A Template for Standards


Putting Applications into the Infrastructure Pattern Portfolio

1. Inventory major and most common application into rough pattern groups Divide complex application into major use case

categories based on who, what, where Match application use cases with patterns Focus on essential use case and component variations Capture description Capture distinguishing service levels Create new sub-patterns when two sets of applications

in a given pattern have sufficiently distinct service level

A 2-Tier Transact pattern could be divided into 2-Tier Transact Fat client and 2-Tier Thin client


Putting Applications into the Infrastructure Pattern Portfolio (cont)

2. Merge use cases that turn out to have no significant difference in service level

3. Analyze results and update draft pattern definitions.Add other descriptive information, conceptual reference architecture

4. Refine the inventory.Capture all component details, standardize terms, capture component de facto standards, and explain deviation

5. Recommendation.Fill in de facto and current standards for component manifest

mti - perencanaan infrastruktur bh-2002/v1.0/1 adaptive infrastructure: identifying and using...

Documents

patterns applications

starter patterns

limited set of patterns

business needs patterns

deployed recognizing

new infrastructure

pattern set

pattern requirements