Developer Exchange Blog
Portals are here to stay. Additionally, the evolution of improving user experience (UXP) continues to be a focus.Tags: Untagged Read More
There is a change coming for traditional enterprise service architecture and deployment environments. Some continue to believe that cloud computing is mosty hype and means little more than providing software via the Internet by hosting services at 3rd party data centers. That's not the case. Continuing to ignore this coming wave of change will be perilous.Tags: PasS, Cloud, Services Read More
There are more gotchas in software than in professional politics, unfortunately. Some are a lot more serious than others and some are downright unforgivable. I've found the lynchpin for mobile development to be, not in the app itself, but in the supporting services.Tags: REST, Web Services, Development, Apple, iOS, iPad, iPhone, Software Read More
A business with ideas has energy and potential. It can breed a culture of excitement, fun, and a sense that something big could happen that could change everything. At the other end of the spectrum, there's the comfort and stability of something that truly works. Don't break it and don't change it is more the feeling here. It's not as fun, but it's something to rely on. While these two are worlds apart, they should, and often do, coexist in any business. A new philosophy is emerging to help businesses better understand this and get better results.Tags: pace layering, IT governance Read More
Have you ever experienced a situation where you needed to recover from a failure but found that despite backup or continuity plans, the restoration expected to be possible was not possible? I've seen this many times over the years. How could this be avoided?Tags: Untagged Read More
Are your processes separating or bringing together your development and operations teams? If you want to get better, look at how the big guys do what they do so well, DevOps.Tags: Untagged Read More
The recent protests known collectively as "Occupy WallStreet" may have a sibling coming soon.Tags: Untagged Read More
It seems like everyone is talking about The Cloud. It may take a while, but once you consider the power and features of a cloud enabled solution, it's pretty compelling. Leading edge? You bet. When will you jump on board?Tags: Untagged Read More
Notes and key takeaways from the respective Gartner session.
Everyone either is or should be considering how Cloud Platforms may affect their IT Strategy.
A platform is almost anything on which you build. Essentially, with regard to cloud computing, platform-as-a-service relates to "middleware in the sky".
Cloud computing starts with someone else being responsible for your hardware. The hardware is not under your control. This is different from hosting. In the cloud many tenants are sharing the resources - costs are different and there is the possibility of flexibility (ability to get more resources when needed). There are many details of what "cloud" is and many variations of "cloudiness".
In the cloud we have a stack of infrastructure: Systems Infrastructure Services (IaaS), Application Infratructure Services (PaaS), Application Services (SaaS).
You can enter the cloud at any of these layers: IaaS, PaaS, SaaS.
With IaaS, you do all the same work you previously did, but you've basically gotten virtualized hardware with the opportunity to scale quickly (no need to order services, you just provision a new VM).
With PaaS, you get some middleware services, but you write the applications, programming to the platforms services. You get full control over the application.
SaaS, everything is done in the cloud. You consume the application directly from the cloud. Some may think that if they provide a web based application and make it available on the Internet on a pay-as-you-go basis, they have SaaS. That would be a very liberal interpretation, at least within the realm of the term Cloud Services. To represent an application as Cloud based, it must be reasonably faithful to the terminology; therefore, it needs to have cloud-like (cloudy) underpinnings (e.g., PaaS).
A typical SOA Application is made up of four layered parts:
- User-Facing Logic, which relies on
- Integration/Composition, which relies on
- Back-end App business Logic, which relies on
- Data Persistence
Within PaaS there are four levels of services emerging (or available) corresponding to the above: uxPaaS, iPaaS, aPaaS, dbPaaS.
Each of us must decide what we will put in the cloud? Data? Data and Business Logic? Everything? All are possible and reasonable and none are the "right answer" for every situation.
The PaaS technology base encompasses several foundational elements:
* Underlying Performance Foundation:
(in-memory computing, grid/massive scale, auto scaling, SLA enforcement, use tracking, high availability, security, data integrity, parallel processing)
* The Cloud Foundation:
(shared resources, multi-tennancy, self service, elasticity, continuous versioning, metadaa management, subscription/Use billing)
* Platform Technology Management:
(monitoring, tuning, administration, version control, resource control)
PaaS is currently near the peak of the hype-cycle. The PaaS market today has a lot of diversity/chaos. Things are in a constant state of emergence/evolution. Many products are at a "Beta" level of maturity. We're headed for the trough of disillusionment.
Gartner believes that aPaaS and iPaaS will be the dominant services.
Comprehensive Application Service is PaaS and it encompasses all forms of PaaS.
Two PaaS models that can be roughly characterized as: High productivity and/or/versus High Control.
The High Productivity model focuses on: ease of use, fast results, fast learning, low cost, elasticity, scalability, default workload types, modern outcomes
The High Control model focuses on: middleware APIs, Access to behavior management, advanced programming, advanced development and design tools, advanced management tools, options, Advanced ALM (testing, fersion control), Advanced QoS of outcomes.
These two models can coexist. Currently most are focused on High Control.
App Server (e.g., JBoss, etc.) --> aPaaS
aPaaS in a private cloud is a "Cloud Enabled Application Platform" (CEAP). CEAP provides value due to the benefits of the cloud model: continuous unintrusive versioning, realtime elasticity, etc. The functional benefits of the cloud are useful even in ones own datacenter. For these reasons, "Over time, Gartner believes all platforms will be cloud enabled." Vendors are realizing there are benefits to all of their products when made cloudy. Expectations are that this will give way to cloudy products being dominant (even when sold to be run privately).
Here are some quick notes on the vendors (note that jotted these down quickly):
* Microsoft: App fabric/Windows Azure. Microsoft has realized that step one was to develop all middleware in the cloud. They have been at this for a couple of years and have a good head start.
* Oracle: to them PaaS is strategic. e.g, Oracle fusion apps.
* IBM: Smartcloud integration services. Was selling "workload deployer" for private cloud use. Now taking this into the public cloud. Beta.
* VMWare and Redhat: Products in Beta. Both are Java based. VMWare striving to partner with others (e.g., Spring Frameworks) enabling others with Cloud Foundry. cloudfoundry.com is VMWares directly available PaaS service - in Beta.
* Salesforce.com is the largest most proven PaaS (force.com). Has the largest real production apps. The problem for them is that they are proprietary. Many do not want to go here due to lock-in - single vendor.
Small and medium business love Cloud because they believe cloud providers enable them to have better platform services than they can build and maintain themselves and at a better price. Larger organizations are the opposite - "we don't trust the cloud", "we believe our own infrastructure is superior" - many times it may more related to closed mindeness and related, perhaps, to job security. "Resistance is futile."
Failing to address PaaS is at your own peril. Learn about it, figure out how (not if) it will benefit you.Tags: Untagged Read More
Notes and key takeaways from the respective Garnter session.
In 2010, Gartner introduced the pace-layered application strategy framework. The reason a new strategy has been necessary is that the conversation between business and IT leaders is not working.
IT is often trying to "standardize technologies and practices" but the business could care less. They just want solutions quickly. Note that this doesn't mean that IT's efforts are pointless, it just means that the efforts to converge technologies (reduce tech footprint) and solidify solid processes and move toward more-perfect releases is not appreciated (understood) by the business. And, further, it means that these efforts are truly not meeting the businesses needs for business related innovation.
Here are some observations leading to and supporting the concept of pace-layering:
- Organizations have a heterogeneous portfolio of business apps - different technologies, different purposes, some as simple a spreadsheets, and this is getting worse not better.
- The apps range from mainframe to iPad, data center to Cloud, critical to casual.
- Business processes change at wildly varying rates: every few years or every few days.
- No single strategy or governance model can be appropriate for all needs/applications.
- Even with efforts in IT attempting convergence, problem is getting worse... just face it, you're not going to get every solution onto a single standardized, converged set of framework, processes and methodologies.
The situation needs to be thought about in a layered way, with appropriate and different policies for the various layers.
Lessons learned from building architecture and the recognition that aspects of a great building's architecture is designed to tolerate change at various frequencies. A well architected building will last for decades or even centuries. It will be repurposed internally. Floors may be reconfigured. The exterior/skin may be changed. The type of tenants may change (e.g., office building, to condo). The necessary internal infrastructure may change (e.g., radiators to high tech EMS). But some things are literally grounded in difficult, if not impossible, to change factors, such as the building's foundation. Pace layering acknowledges this and applies the concept to the enterprise application portfolio.
The Pace-Layered View of Apps is that they fit into one of three "layers":
- Systems of innovation (New Ideas, Addressing immediate Competitive Threats)
- Systems of Differentiation (Iterating to Better Ideas, Building Unique Processes)
- Systems of Record (Empowering Greater Efficiency, Supporting established Common Ideas)
- Master Data Management
- Process and Data Integration tools
- Business Service Repository
- Integrated Composition Technology
- Common Security Architecture
- Integrated Monitoring and Management
- External Connectivity
- create a panel of users and IT app experts
- decompose existing suites into individual apps
- associate each app with the business process it supports
- analyze the characteristics of each app and process
- use the pace-layering model to assign each app to a layer
- adapt a governance model that works for each of the layers, especially including the innovation layer - meaning get out of the way and let innovation happen!
- establish connective technologies to facilitate interoperability
Notes and key takeaways from the Gartner session on cloud operating models.
Assertion: Enterprise IT is crumbling under the weight of its "debt" due to complexity.
"All problems of computer science can be solved by another layer of indirection... except for the problem of too many layers of indirection." --David Wheeler
What does DevOps mean? "Occupy IT" it's about changing the way services are delivered.
Complex Information Technology + Bureaucratic Operations Processes = IT Debt
One way to calculate IT Debt is: Actual cost of change minus the Optimal cost of change.
62% of the functionality being paid for in IT is NEVER or RARELY used.
The cost of IT service delivery goes down along this chain:
- Traditional Enterprises
- The Virtual Enterprise (virtualization, etc.)
- Enterprise/On-premises Clouds
- Public Clouds (e.g., google/amazon)
"The cloud is ultimately less important than the cloud operating model."
The following are characteristic of DevOps:
Resilient Application Architectures
- Programmable infrastructure
- Open Source
- Continuous delivery/release
- Version control
- Value streams
- Shared metrics
- Embrace Risk
- Avoid Blame
- Value Creation
- Two-pizza teams
Boiling the concept of DevOps down, it's:
- Improving collaboration and communication between development and operations teams.
- An adoption of methodologies (and some technologies) used in software development by operations teams.
- A renaissance of infrastructure technologies.
DevOps objectives: It's about driving business value.
- Deliver measurable business value through continuous and high-quality service delivery
- Emphasize simplicity and agility in all areas, including technology, process and human factors.
- Break down barriers between dev and ops by enabling trust and shared ownership, supporting innovation.
- Continuously re-optimize in response to changing business, technology and operational requirements
- Enable the reconstruction of the business from essentially nothing but a source code repository, an application data backup and bare metal resources
- Develop shared metrics -> focus organization on the end goal
- Done means released -> code deploy not code complete
- Separate code from configuration -> Configuration is code and needs controls
- Use test as brakes to go faster -> testing improves throughput
- If it's hard, do it more often ->practice makes perficient
Example, Chaos Monkey at Netflix randomly turns off pieces of their infrastructure IN PRODUCTION. This causes/caused their ops team to get VERY good at service restoration because they have to be on their toes all the time - quickly diagnosing the failure and restoring service.
There is no "manual" for DevOps. DevOps borrows "just enough" best practices from multiple places: Agile, Kanban, Lean IT, OODA (observe-orient-decide-act), ITIL. It's not a pure adoption of any of these, more like taking the most helpful aspects from each as a blend.
DevOps Practice "Heat Map"
Strategize and plan
- Establish technical debt
Architect Solution: Decompose, make simple
Build and Deploy
- Educate operations on the code
- Employ test-driven development
- Automate the build/rel process
- Implement one-step build/deploy
- Deploy the same way to EVERY ENVIRONMENT
- Always ship the code trunk
- Implement code feature and configuration flags (ability to turn features off)
- Develop post-commit hooks for notification
- Subject mgmt. code to same discipline as functional code
- Logging needs to be interpretable and actionable
Operate and Evolve
- Share road maps and upgrade plans
- Employ test-driven deployment
- Automation is code and needs SDLC management
- Treat processes like apps and build error handling into them
- Boot instances from bare minimum packages
- Object role and behavior are no longer fixed
- Reuse management tooling from the dev/test environment
Dev Ops Organization
From the Agile Manifesto: Individuals and interactions over tools and processes.
- Smaller is better (Amazon two-pizza rule... team should be small enough that two-pizzas can feed the team)
- Self organizing is better
- Pairing activities is better
- Face-to-face is better
- Empowered is better
DevOps impact: Ending the Enterprise Process Framework "Cargo Cult"
- Just enough, not best practice
- Fit the process to the reality, not vice versa
- Create an ownership, not employee, society
- Results not CYA-oriented
- Tasks are selected, not assigned
- Bottom-up not top-down-driven
- Practitioner not consultant-derived
- Reward creativity, not conformance
- Emphasize contributions, not credentials
DevOps Impact: Solving the paradox of being both Agile and in Control.
By 2015 DevOps will evolve from a niche strategy employed by large cloud providers into a mainstream strategy employed by 20% of Global 2000 organizations.
As a side note, Doozer's internal processes have been very much dev-ops like for years and years. This comes from our Java application development and deployment models and philosophical approach to making build-release really simple, non-disruptive and easy to roll-out and roll-back.Tags: Untagged Read More
Notes and key takeaways from the 2012 CIO Agenda session at the 2011 Gartner IT Symposium.
The role of technology in business is increasing, but that does not necessarily mean that the role of IT is increasing. IT has been an ingredient for success, but now technology is the business.
Now there is a commercially definable standard for cost, quality, service and it's coming from the cloud. IT can no longer exist under the shield of fear-uncertainty-and-doubt.
Re-imagination is about finding new answers to new questions, not new answers to old questions.
Re-imagining IT requires creative destruction. What am I going to sacrifice in my existing structure/budget to push forward?
2012 top-4 priorities: Increasing enterprise growth, attracting and retaining customers, creating new products or services (innovation), improve operational performance.
2011 top-4 priorities: Increasing enterprise growth, attracting and retaining customers, reducing costs, improving business processes.
Only 31% of activities are rated as unique to the business or yielding competitive advantage in the market. This is a big problem because this is where IT should be focused.
Too much of what's being worked on is simply not significant to the business.
2012 Global CIO Technology Priorities according to a worldwide Gartner survey:
- Cloud computing
- Collaboration Technologies
- Legacy Modernization
- IT Management
- ERP Apps
- Mobile Technologies
"Let anyone write any app, as long as access to the information is controlled."
To get quick results:
- Leverage existing public infrastructure.
- Leverage existing data.
- Assume that your end user is an idiot (i.e., make it simple).
The biggest digitization gap is in customer sales and service. This is where the biggest opportunities exist.
Delivering a new value proposition requires recasting IT resources and skills. At the top of the list from the perspective of effectiveness and frequency is:
- Use of contractors
- Skills outsourcing
- Internal training
These are the places to focus efforts for maximum return. Use contractors and infuse them into your organization. You get mentoring and more immediate results. The value proposition is high.
Re-imaging IT requires a different focus to create different value.
It use to be about: Scope, On-time, on budget.
Now it's about: Choice, Speed and Scale
Focus on: Cycle time, productivity, throughput. How quickly can you respond to requests from the business?
Tags: Untagged Read More
For too long, Enterprise Architecture has been driven by the domain of IT. This must change going forward and it must be driven by business strategy and focused on delivering business results. A key trend is moving EA closer to the business and having EA be a driver for delivering business value, more directly.Tags: Untagged Read More