The scaling iq test when dev and admin collide
Download
1 / 23

The Scaling IQ Test: When Dev and Admin Collide - PowerPoint PPT Presentation


  • 102 Views
  • Uploaded on

The Scaling IQ Test: When Dev and Admin Collide. Richard Campbell Strangeloop Networks. Richard Campbell. Background After thirty years, done every job in the computer industry you’ve ever heard of Currently Co-Founder and Product Evangelist for Strangeloop Networks Co-Host of .NET Rocks!

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' The Scaling IQ Test: When Dev and Admin Collide' - susane


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
The scaling iq test when dev and admin collide

The Scaling IQ Test: When Dev and Admin Collide

Richard Campbell

Strangeloop Networks


Richard campbell
Richard Campbell

  • Background

    • After thirty years, done every job in the computer industry you’ve ever heard of

  • Currently

    • Co-Founder and Product Evangelist for Strangeloop Networks

    • Co-Host of .NET Rocks!

    • Host of RunAs Radio


The it dev meeting
The IT/Dev Meeting

  • Every web application has this meeting eventually

  • Sooner is always better

  • The goal is to trade information

    • What IT needs to know about the app

    • What Dev needs to know about the operating environment


The it dev meeting1
The IT/Dev Meeting

  • Who needs to be in the room?

    • The architect/senior dev

    • Seniors devs that know the features in detail

    • IT personnel that will operate the application

    • Senior personnel that know the entire network


The it dev meeting2
The IT/Dev Meeting

  • When does the meeting need to happen?

    • When the application is being designed (collected as requirements)

    • While the application is being developed

    • After the application is deployed

    • After the application has crashed horribly

    • When the application is too slow


The it dev meeting3
The IT/Dev Meeting

  • Starting the meeting

  • What are the priorities

    • Reliability

    • Performance

    • Scalability

    • Accuracy

  • Put them in order, every site has different priorities


The it dev meeting4
The IT/Dev Meeting

  • What IT Needs to Know

    • What’s in the web.config file (a great starting point)

    • What load balancing strategies will work for the application

    • Any known performance bottlenecks


Web config
Web.Config

  • <authorization>

    • None (Anonymous)

    • Windows (Active Directory, Basic, etc)

    • Forms-Based


Web config1
Web.Config

  • <appSettings>

    • Global connection strings, paths etc

    • Make sure they’re being used!

    • Remove dead strings

    • These can be critical in failover/disaster recovery scenarios


Web config2
Web.Config

  • <customErrors>

    • Decide on how errors should be displayed to the customer (internal or external)

    • Defaults are really not enough

    • You can create separate pages for each error (handle 404 page not found differently from 500 internal server error)


Web config3
Web.Config

  • <sessionState>

    • In-process vs. out-of-process

    • More dependencies

    • Affects options around load balancing


Load balancing
Load Balancing

  • Find out what load balancing will work with the application

  • In-process session requires “sticky” load balancing

    • You only get to load balance the first request

  • Talk through server failure effects


Performance bottlenecks
Performance Bottlenecks

  • Discuss known performance issues

    • Night time processing that conflicts with existing work

    • Administrators work that significant impacts performance of regular users

  • What parts of the application are more scalable than others?


Things dev need to know
Things Dev Need to Know

The Network Diagram (in detail!)

How to get at production log data

What redundacy/failover/disaster recovery options there are


The network diagram
The Network Diagram

How developers see it


The network diagram1
The Network Diagram

Closer to reality


Production logs
Production Logs

  • Production logs are the truth of what happened with the application

  • Providing developers with production logs gives them a chance to help out

    • Provide access to the backups of the logs

    • Saying “I’ll give them to you when you ask” is not enough

    • You’re looking for proactive analysis


Disaster recovery
Disaster Recovery

  • All DR strategies require at least some coding support

    • SQL Server failover still needs to have queries retried to be seamless

    • What happens between the time a server fails and the load balancing strategy detects it?

    • Is losing request acceptable in your scenario?


Disaster recovery1
Disaster Recovery

  • Switching to a backup site

    • Are DNS changes needed?

    • What references within the application need to be changed?

    • What does a switch-back look like?

  • Practice practice practice!

    • Don’t let your first failover test with an application be a real failure!


After the meeting
After the Meeting

  • What follow ups are there for management?

    • You’ve probably made some business-related decisions, make sure you have buy-in

  • When do we need to meet again?

    • Preferably before the next disaster


The cooperative firefight
The Cooperative Firefight

  • IT is invariably on the front lines of an application failure

    • But when should development be brought in?

    • Post-mortem is often not enough


The cooperative firefight1
The Cooperative Firefight

  • Make a strategy to involve development during the firefight

    • They often have deep insight into how the application works and so can understand why it might fail

    • Just make sure they’re educated to not make the problem worse

    • This is NOT a time for fixing code


Summary
Summary

Have the meeting early

Repeat as necessary

Each group must learn from the other

Assist and seek assistance during a firefight


ad